ICMP frag needed not forwarded to MSQ clients

ICMP frag needed not forwarded to MSQ clients

[Leonardo]

Hello to all!

My box does not forward ICMP Fragmentation needed packet to
its masqueraded clients.

Setup:
I have a box with 3 nics equipped with kernel 2.6.11 and iptables
1.2.11. This box has two gateways, and the net workflow is as follows:

eth0 <---> clients
eth1 <---> standard internet traffic
eth2 <---> VPN

Details:
Traffic on eth2 is masqueraded (required). The problem is that the
packets (MTU 1500) must be encapsulated in IPSEC packets at the next
hop where the MTU is the same, therefore the VPN server sends back
ICMP packet telling that need to frag. ICMP packets are received by my
box, but not forwarded to clients that continue to send 1500 bytes
packets. Therefore the VPN site does not open.

Is that a normal behavior? Should I add anything to iptables rules in
order to make it forwarding ICMP Frag needed packets?

Thank you very much!

Iptables on eth2,eth0:
Input,Output,Forward
- Policy ACCEPT (nothing else)
Only on eth2:
Nat
- POSTROUTING anywhere anywhere -j MASQUERADE

Current Workaround:
- ifconfig eth2 mtu 1400 (I don't like it! :)v
-- 
Leonardo Arena

Re: ICMP frag needed not forwarded to MSQ clients

[Leonardo]

> Have you tried the TCPMSS target ? I think it have been created to solve this
> problem.
> 
> Brice
> 

Yes! Of course!

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

And it does not work! As far as I understand as man pages say, this is
a workaround if you are *behind* a router that block ICMP frag needed
packets, but this packets *are* received at my routerbox but *NOT*
unmasked&forwarded to the source host.

-- 
Leonardo Arena

Re: ICMP frag needed not forwarded to MSQ clients

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 25 May 2005, Leonardo wrote:

> Hello to all!
>
> My box does not forward ICMP Fragmentation needed packet to
> its masqueraded clients.
>
> Setup:
> I have a box with 3 nics equipped with kernel 2.6.11 and iptables
> 1.2.11. This box has two gateways, and the net workflow is as follows:
>
> eth0 <---> clients
> eth1 <---> standard internet traffic
> eth2 <---> VPN
>
> Details:
> Traffic on eth2 is masqueraded (required). The problem is that the
> packets (MTU 1500) must be encapsulated in IPSEC packets at the next
> hop where the MTU is the same, therefore the VPN server sends back
> ICMP packet telling that need to frag. ICMP packets are received by my
> box, but not forwarded to clients that continue to send 1500 bytes
> packets. Therefore the VPN site does not open.
>
> Is that a normal behavior? Should I add anything to iptables rules in
> order to make it forwarding ICMP Frag needed packets?
>
> Thank you very much!
>
> Iptables on eth2,eth0:
> Input,Output,Forward
> - Policy ACCEPT (nothing else)
> Only on eth2:
> Nat
> - POSTROUTING anywhere anywhere -j MASQUERADE
>
> Current Workaround:
> - ifconfig eth2 mtu 1400 (I don't like it! :)v


have you a;

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMMS \
- --clacmp-mss-to-ptmu


kind of statment in your rules, often require with VPN/s that work with 
smaller packet sizes due to increasing headers...


Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFClKcQst+vzJSwZikRAg3bAJ93j5nlWUFmQ1a2Ro6+4qCEacwXlQCfUqUP
cRFo0QZX65uSLBaHmh+24AA=
=lScV
-----END PGP SIGNATURE-----

Re: ICMP frag needed not forwarded to MSQ clients

[Leonardo]

> 
> 
> have you a;
> 
> iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMMS \
> - --clacmp-mss-to-ptmu

Yes! I did it! And it does't work... :-(
 
> 
> kind of statment in your rules, often require with VPN/s that work with
> smaller packet sizes due to increasing headers...

That's exactly the problem! The clients should receive an ICMP frag
needed packet in order to reduce the packet size, however my
proxy/router does not forward the ICMP msg to them! WHY?!?!?!
The are no iptables rules that block ICMP!
> 
> 
> Thanks,
> 
> Ron DuFresne
> - --

Thanks to you!

-- 
Leonardo Arena

Re: ICMP frag needed not forwarded to MSQ clients

[Jozsef Kadlecsik]

On Thu, 26 May 2005, Leonardo wrote:

> That's exactly the problem! The clients should receive an ICMP frag
> needed packet in order to reduce the packet size, however my
> proxy/router does not forward the ICMP msg to them! WHY?!?!?!
> The are no iptables rules that block ICMP!

As you have no DROP rule, netfilter does not drop the packets so it's not
a netfilter/iptables related problem.

Probably you have got rp_filtering enabled and the routing engine discards
the ICMP packets.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: ICMP frag needed not forwarded to MSQ clients

[Leonardo]

On 5/26/05, Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:
> On Thu, 26 May 2005, Leonardo wrote:
> 
> > That's exactly the problem! The clients should receive an ICMP frag
> > needed packet in order to reduce the packet size, however my
> > proxy/router does not forward the ICMP msg to them! WHY?!?!?!
> > The are no iptables rules that block ICMP!
> 
> As you have no DROP rule, netfilter does not drop the packets so it's not
> a netfilter/iptables related problem.

May be it's like you say... but really i do not have idea where else
to look for...

> Probably you have got rp_filtering enabled and the routing engine discards
> the ICMP packets.
>

Yes, I have it enabled. Disabling it does not solve the problem... :-(

echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter

ICMP packets type 3 are NOT routed anyway...

> Best regards,

> Jozsef
> -

Thank you.
-- 
Leonardo Arena

Re: ICMP frag needed not forwarded to MSQ clients

[Jozsef Kadlecsik]

On Thu, 26 May 2005, Leonardo wrote:

> > Probably you have got rp_filtering enabled and the routing engine discards
> > the ICMP packets.
>
> Yes, I have it enabled. Disabling it does not solve the problem... :-(
>
> echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter
> echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter

Can you verify by tcpdump that the ICMP packets do received on eth2?
Can you see them going out on eth0? Anything in the kernel log?

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: ICMP frag needed not forwarded to MSQ clients

[Leonardo]

On 5/26/05, Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:
> 
> Can you verify by tcpdump that the ICMP packets do received on eth2?
> Can you see them going out on eth0? Anything in the kernel log?
> 
> Best regards,
> Jozsef
> -

I'm currently sniffing on client and server side (eth0/2). Yes, ICMP
Frag Needed msg are received at eth2. However they are not received
from the client nor sent from eth0. The browser just hang, a session
is established but data is incomplete and finally it simply timeout...

Thank you!
-- 
Leonardo Arena

Re: ICMP frag needed not forwarded to MSQ clients

[Jozsef Kadlecsik]

On Thu, 26 May 2005, Leonardo wrote:

> On 5/26/05, Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:
> >
> > Can you verify by tcpdump that the ICMP packets do received on eth2?
> > Can you see them going out on eth0? Anything in the kernel log?
>
> I'm currently sniffing on client and server side (eth0/2). Yes, ICMP
> Frag Needed msg are received at eth2. However they are not received
> from the client nor sent from eth0. The browser just hang, a session
> is established but data is incomplete and finally it simply timeout...

Do the packet correspond to what you expect as ICMP reply packet: src and
dst IP addresses are OK? What's inside the packet, i.e the src/dst IP,
protocol, ports inside the ICMP error message are OK?

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: ICMP frag needed not forwarded to MSQ clients

[Leonardo]

On 5/26/05, Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:
>
> Do the packet correspond to what you expect as ICMP reply packet: src and
> dst IP addresses are OK? What's inside the packet, i.e the src/dst IP,
> protocol, ports inside the ICMP error message are OK?
>
> Best regards,
> Jozsef
> -

Everything seems to be ok... src is the next hop after the gateway on
eth2 (the VPN box), dst is eth2, TCP ports are ok. ICMP msg correctly
encapsulate the previos IP datagram (ACK number correspond) that needs
fragmentation...
On the other hand ICMP echo packets works correctly, they report the
same dst (eth2) and are correctly unmasqueraded and forwarded to the
client...

Could it be something distribution-related setting or patch?
I'm using Gentoo.
Thank you
--
Leonardo Arena

Re: ICMP frag needed not forwarded to MSQ clients

[Jozsef Kadlecsik]

On Fri, 27 May 2005, Leonardo wrote:

> On 5/26/05, Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:
> >
> > Do the packet correspond to what you expect as ICMP reply packet: src and
> > dst IP addresses are OK? What's inside the packet, i.e the src/dst IP,
> > protocol, ports inside the ICMP error message are OK?
>
> Everything seems to be ok... src is the next hop after the gateway on
> eth2 (the VPN box), dst is eth2, TCP ports are ok. ICMP msg correctly
> encapsulate the previos IP datagram (ACK number correspond) that needs
> fragmentation...
> On the other hand ICMP echo packets works correctly, they report the
> same dst (eth2) and are correctly unmasqueraded and forwarded to the
> client...
>
> Could it be something distribution-related setting or patch?
> I'm using Gentoo.

Dunno. It should work out of the box.

Enable debugging in net/ipv4/netfilter/ip_conntrack_proto_icmp.c by
changing

#if 0
#define DEBUGP printk

to

#if 1
#define DEBUGP printk

at the head of the file. Then recompile and boot with the new kernel.
Also, load in the ipt_LOG module and switch on internal logging in
netfilter/conntrack by

echo 255 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid

Then repeat the tests and watch the kernel log.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary