"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 | 