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,
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:
> <descr>ICMP Type 3 Allow</descr>
> 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:
>> 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:
>> <descr>IPSec Path MTU Correction</descr>
>> 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:
>>>> 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,
>>>> it doesn't feel proper. I've got two m0n0wall's (v1.33) set up as the
>>>> 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
>>>> 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
>>>> connection works like a charm. What I think is happening is this: The
>>>> 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?
>>>> Mike Robison