[ previous ] [ next ] [ threads ]
 
 From:  Michael Brown <knightmb at knightmb dot dyndns dot org>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Re: AW: Problem with IPSec VPN Tunnel - MTU-Size?
 Date:  Wed, 13 Feb 2008 13:49:33 -0600
The only variable was the ISP, I would plug in the AT&T connection and 
it worked (by just changing the static IP on both ends so the IPSec 
Tunnel works again), then switching back to Comcast, it stopped working. 
The only change being the static IP address to connect the two. It's 
possible it wasn't ISP related, but when it's the only variable it kind 
of points the finger at Comcast in that situation.

I didn't have time to go into depth as the customer was losing vast 
amounts of time and money waiting for me to get the financial bank links 
back up and working. So since I've never encountered this problem since 
then, I chalked it up to some ISP issue (maybe Comcast was cutting into 
the VPN packets, they have been trouble lately for a lot of that deep 
packet  inspection and blocking).  But my only solution at the time was 
to set the server MTU to 1400 and for some reason, it would work again 
across the Comcast link when it never worked before. This wasn't just a 
windows to windows issue, I could duplicate it across Linux and Mac OS 
10 NFS. The only thing that did work across the link before the change 
was simple ping test with the don't fragment flag set using sizes of 
1400 and less (that's how I came up with that number that would work 
through trial and effort).

Again, I've never seen the problem since then. But I haven't run into 
another Comcast -> Another ISP IPSec tunnel setup yet.  So "knock on 
wood", maybe it's just a glitch I won't ever see again. :-)

Might be m0n0wall, but I tend to look at some weird Comcast issue since 
they were the only variable in that situation.


> "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 
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>
>