[ previous ] [ next ] [ threads ]
 
 From: 
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: AW: Problem with IPSec VPN Tunnel - MTU-Size?
 Date:  Thu, 14 Feb 2008 23:31:19 +0200
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


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