[ previous ] [ next ] [ threads ]
 
 From:  Steven Nusser <jaguar11735 at gmail dot com>
 To:  Mike Robison <mrobison at wts dot edu>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] ssh over an ipsec site to site tunnel
 Date:  Wed, 25 Jan 2012 14:09:57 -0500
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
>>>>>
>>>>
>>>>
>>>
>>
>