[ previous ] [ next ] [ threads ]
 
 From: 
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: AW: Problem with IPSec VPN Tunnel - MTU-Size?
 Date:  Wed, 13 Feb 2008 21:36:54 +0200
"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)
vm2: monowall (IPSec NAT-T server)
         |  (wan)
         |
   ethernet - mtu 1500 - (access to public internet)
         |
         |  (wan)
vm3: monowall (just a firewall to have NAT)
         |  (lan)
         |
   ethernet - mtu 1500
         |
         |  (wan)
vm4: monowall (IPSec NAT-T client)
         |  (lan)
         |
   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