|
||||||||
I repeated test-case using (latest) m0n0wall 1.3b9. I tested the following connections: 1. WinXP -> WinXP remote desktop connect 2. WinXP -> Debian etch scp copy 3. Debian etch -> Debian etch scp copy All of them FAILed. Here is copy paste of "scp" failure between Debian nodes: CASE 1: scp is started in vm5 and it should transfer file from _vm5_ to _vm1_) These (FAIL) entries and generated by m0n0wall _vm2_ Feb 14 22:21:41 192.168.121.138 ipmon[101]: 19:46:49.829131 enc0 @0:22 p 10.50.1.199,4686 -> 10.30.1.200,22 PR tcp len 20 60 -S K-S K-F IN Feb 14 22:21:43 192.168.121.138 ipmon[101]: 19:46:50.779458 lnc0 @200:1 b 192.168.121.139 -> 192.168.121.138 PR udp len 20 (80) (frag 70:60@1480) IN Feb 14 22:21:43 192.168.121.138 ipmon[101]: 19:46:50.779460 lnc0 @200:1 b 192.168.121.139 -> 192.168.121.138 PR udp len 20 (80) (frag 71:60@1480) IN Feb 14 22:21:43 192.168.121.138 ipmon[101]: 19:46:50.890525 lnc0 @200:1 b 192.168.121.139 -> 192.168.121.138 PR udp len 20 (80) (frag 72:60@1480) IN Feb 14 22:21:43 192.168.121.138 ipmon[101]: 19:46:51.117371 lnc0 @200:1 b 192.168.121.139 -> 192.168.121.138 PR udp len 20 (80) (frag 74:60@1480) IN Feb 14 22:21:43 192.168.121.138 ipmon[101]: 19:46:51.541418 lnc0 @200:1 b 192.168.121.139 -> 192.168.121.138 PR udp len 20 (80) (frag 75:60@1480) IN CASE 2: scp is started in vm5 and it should transfer file from _vm1_ to _vm5_) These (FAIL) entries and generated by m0n0wall _vm4_ Feb 14 23:22:09 10.40.1.200 ipmon[101]: 20:30:12.839729 lnc1 @100:2 p 10.50.1.199,4144 -> 10.30.1.200,22 PR tcp len 20 60 -S K-S K-F IN Feb 14 23:22:09 10.40.1.200 ipmon[101]: 20:30:13.720702 lnc0 @200:1 b 192.168.121.138 -> 10.40.1.200 PR udp len 20 (80) (frag 809:60@1480) IN Feb 14 23:22:09 10.40.1.200 ipmon[101]: 20:30:13.720716 lnc0 @200:1 b 192.168.121.138 -> 10.40.1.200 PR udp len 20 (80) (frag 810:60@1480) IN Feb 14 23:22:09 10.40.1.200 ipmon[101]: 20:30:13.840919 lnc0 @200:1 b 192.168.121.138 -> 10.40.1.200 PR udp len 20 (80) (frag 812:60@1480) IN Feb 14 23:22:09 10.40.1.200 ipmon[101]: 20:30:14.038729 lnc0 @200:1 b 192.168.121.138 -> 10.40.1.200 PR udp len 20 (80) (frag 813:60@1480) IN Feb 14 23:22:09 10.40.1.200 ipmon[101]: 20:30:14.452559 lnc0 @200:1 b 192.168.121.138 -> 10.40.1.200 PR udp len 20 (80) (frag 814:60@1480) IN regards, Marek "Marek Läll" <marek dot lall at neti dot ee> wrote in message news:fovgt6$626$1 at ger dot gmane dot org... > > "Michael Brown" <knightmb at knightmb dot dyndns dot org> wrote in message > news:47B31F76 dot 1060105 at knightmb dot dyndns dot org... >> or whatever). The problem that I had though was not the IPSec Tunnel, but >> the actually ISP was having problems with the MTU setting between two >> different ISP (in that case, it was Comcast to AT&T). The m0n0wall >> machines I setup, one machine was behaving like a hub for more others >> across the Internet. One site, which never had any problems nor > > > I disagree that the root cause is related with ISP configuration. > My statement is that is bug (or undocumented feature) of m0n0wall of > FreeBSD. > > I have run into the same issue and finally I prepared the following > sandbox using vmware and it is easy to repeat that problem at will: > > ----------------- > vm1: WinXP (remote desktop server) > | > ethernet - mtu 1500 > | > | (lan - 10.30.1.33) > vm2: monowall (IPSec NAT-T server) > | (wan - 192.168.121.138) > | > ethernet - mtu 1500 - (access to public internet) > | > | (wan - 192.168.121.139) > vm3: monowall (just a firewall to have NAT) > | (lan - 10.40.1.33) > | > ethernet - mtu 1500 > | > | (wan - 10.40.1.200) > vm4: monowall (IPSec NAT-T client) > | (lan - 10.50.1.33) > | > ethernet - mtu 1500 > | > vm:5 WinXP (remote desktop client) > ---------------- > > My point is that every MTU on every interface is 1500 but it still does > not work. > > + I can ping vm1 from vm5 successfully. > + I can open and edit small files stored on vm1 using notepad on vm5 > > - I can NOT open remote desktop session from vm5 to vm1 > - I can NOT open and edit bigger files (~> 1450 bytes) stored on vm1 using > notepad on vm5 > > According to my skills of tracing I made the following conclusion: > Bug/feature appears in vm4. Explanation: > 1. user wants to open remote desktop of vm1 from vm5 > 2. success: vm4 sends ESP packet (encapsulated inside UDP) to vm2 > 2. success: vm2 responts with ESP packet (encapsulated inside UDP) to vm4 > 3. fail: vm4 firewall log shows that this ESP packet (encapsulated inside > UDP) is dropped > and syslog shows that it is "bad" > > > Here is copy-paste from syslog (generated by m0n0 1.3b3): > Aug 1 22:10:39 gw ipmon[91]: 22:10:38.719266 ng0 @0:21 b x.x.30.170 -> > x.x.151.153 PR udp len 20 (756) (frag 35648:736@744+) IN > Aug 1 22:10:39 gw ipmon[91]: 22:10:38.719924 ng0 @0:21 b x.x.30.170 -> > x.x.151.153 PR udp len 20 (80) (frag 35648:60@1480) IN bad > > > regards, > Marek |