|
||||||||||
I wonder, in the research you were doing did you happen to see what versions of FreeBSD are affected by this? m0n0wall 1.33 uses FreeBSD 6, which is older. There are alpha/beta versions of m0n0wall available that are based off FreeBSD 8, which perhaps are worth a shot? -- Steven C. Nusser On Wed, Jan 25, 2012 at 1:50 PM, Mike Robison <mrobison at wts dot edu> wrote: > Ok. So I tried this rule, and it didn't work either. But I really didn't > expect it to work because I already was allowing everything to pass through > the ipsec interface. I've done a bit more research, and I came across this > comment on another site: "Racoon (or FreeBSD, more likely) breaks PMTUD > with IPsec because it doesn't take the IPsec overhead into account. So > packets end up larger than the 1500 or 1492 MTU on the WAN and just > disappear." The more I look around, on FreeBSD lists, the more this looks > to be the problem (I find folks speaking of pfSense and M0n0wall in the > same breath usually). > So it does look like for now the only solution is to manually set the MTU > on my client, unless you have further suggestions. > I think you've pointed me in the right direction with PMTUD, so I'm > grateful for that. > Thanks for your help, > Mike Robison > > > On Wed, Jan 25, 2012 at 12:17 PM, Steven Nusser <jaguar11735 at gmail dot com>wrote: > >> Perhaps try setting the rule on the IPSec interface, like this: >> >> <rule> >> <type>pass</type> >> <interface>ipsec</interface> >> <protocol>icmp</protocol> >> <icmptype>unreach</icmptype> >> >> <source> >> <any/> >> </source> >> <destination> >> <any/> >> </destination> >> <frags/> >> <descr>ICMP Type 3 Allow</descr> >> </rule> >> >> A round-about way I use to test MTU issues is to just use ping. At least >> on windows, the -l option allows you to specify the size of the packet - if >> you set it to 1500 and it times out, you know the MTU is the issue. You can >> then gradually step that size down until it goes through, then you'll know >> the max MTU. >> >> -- >> Steven C. Nusser >> >> >> >> On Wed, Jan 25, 2012 at 11:26 AM, Mike Robison <mrobison at wts dot edu> wrote: >> >>> Steven, >>> That was a really interesting idea. And it makes sense. Sadly, I >>> just tried it and it doesn't seem to work for me. Just to make sure I >>> understood you correctly, I set up the following firewall rule on both >>> firewalls: >>> <rule> >>> <type>pass</type> >>> <interface>wan</interface> >>> <protocol>icmp</protocol> >>> <source> >>> <any/> >>> </source> >>> <destination> >>> <any/> >>> </destination> >>> <descr>IPSec Path MTU Correction</descr> >>> </rule> >>> I don't know if the following impacts this, but earlier I turned on >>> "Allow fragmented IPSec packets" on both m0n0walls. Perhaps, by setting >>> that, I turned PMTUD off? >>> Mike Robison >>> >>> >>> On Wed, Jan 25, 2012 at 11:03 AM, Steven Nusser <jaguar11735 at gmail dot com>wrote: >>> >>>> How is your firewall configured? In order for PMTUD (Path MTU >>>> Discovery) to function correctly, ICMP 'Destination Unreachable' messages >>>> must be permitted through the firewall. At least on my m0n0wall devices, I >>>> typically allow all ICMP traffic through, although you should have the >>>> option to only allow that specific ICMP type through. Setting this should >>>> allow your computer to detect the lower MTU of the IPSEC link, and send >>>> packets accordingly. >>>> >>>> -- >>>> Steven C. Nusser >>>> >>>> >>>> >>>> On Wed, Jan 25, 2012 at 10:51 AM, Mike Robison <mrobison at wts dot edu>wrote: >>>> >>>>> Hi, >>>>> I'm attempting to run an ssh connection over an ipsec site to site >>>>> tunnel and I'm running into MTU issues. I have a workaround that >>>>> works, but >>>>> it doesn't feel proper. I've got two m0n0wall's (v1.33) set up as the >>>>> end >>>>> points in the ipsec tunnel, connecting two subnets. Running ifconfig on >>>>> either tells me that the MTU is at 1500. When I attempt to ssh from one >>>>> subnet to the other, the connection hangs when running commands like >>>>> ls -la >>>>> or ps aux. After some poking around, I found that both my ssh client >>>>> and >>>>> server have their MTU set to 1500. I changed the client to 1440 and >>>>> the ssh >>>>> connection works like a charm. What I think is happening is this: The >>>>> ipsec >>>>> tunnel is not properly reforming the ssh packets at end of the tunnel, >>>>> thereby causing the ssh tunnel to collapse. >>>>> Has anyone else discovered a better solution than modifying the MTU >>>>> of >>>>> the ssh client? That is to say, is there a suggested way of ensuring >>>>> the >>>>> ipsec tunnel properly reforms the packets in M0n0wall itself? Or do I >>>>> actually not understand what is going here? >>>>> Thanks, >>>>> Mike Robison >>>>> >>>> >>>> >>> >> > |