Re: FreeBSD 6.1 IPsec Path MTU Discovery

2006-11-09 Thread Johann Hugo 
On Tuesday 07 November 2006 19:39, Tom Judge wrote:
 Hi,

 I am seeing some problems with some problems with IPsec encrypted gif
 tunnels and path mtu discovery.

 It seems that the router with the IPsec tunnel sends an ICMP need to
 frag packet with the next hop mtu set to 0. This causes ssh to
 retransmit a the same packet without reducing the size of the data payload.

 Is this a know problem? If so are there any know work arounds?

I'm seeing the same problem on my gif tunnel.

For an interim work around you can reduce the MTU size between Box1 and Box2 
e.g route change Box2 -mtu 1200. After it's starts working you can change it 
back to 1500 en it keeps on working. 
 
Don't ask me why it works, I'm still trying to figure out what the problem is.

Johann
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: FreeBSD 6.1 IPsec Path MTU Discovery

2006-11-09 Thread Tom Judge 

Johann Hugo wrote:

On Tuesday 07 November 2006 19:39, Tom Judge wrote:

I'm seeing the same problem on my gif tunnel.

For an interim work around you can reduce the MTU size between Box1 and Box2 
e.g route change Box2 -mtu 1200. After it's starts working you can change it 
back to 1500 en it keeps on working. 
 
Don't ask me why it works, I'm still trying to figure out what the problem is.


Johann


I have a patch for the problem,  it is related to a broken peice of code 
that is supposed to calculate the mtu using the size of the ip header 
and the size of the ipsec header.  However when the ipsec security 
policy is fetched some required sections are null and the code block 
completely fails.  The following patch fixes the problem for me as it 
allows the code to fall through to the standard mtu calculation using 
either the destination interface mtu or by calculating the next smallest 
rfc defined mtu.


It would be interesting to see if this patch works for you, I have 
submitted it on the open pr but have not had a response yet.



Tom J

PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/91412

Patch:

Index: sys/netinet/ip_input.c
===
--- sys/netinet/ip_input.c  (revision 24)
+++ sys/netinet/ip_input.c  (working copy)
@@ -1990,8 +1990,8 @@
 #else /* FAST_IPSEC */
KEY_FREESP(sp);
 #endif
-   ipstat.ips_cantfrag++;
-   break;
+// ipstat.ips_cantfrag++;
+// break;
}
}
 #endif /*IPSEC || FAST_IPSEC*/

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

FreeBSD 6.1 IPsec Path MTU Discovery

2006-11-07 Thread Tom Judge 

Hi,

I am seeing some problems with some problems with IPsec encrypted gif 
tunnels and path mtu discovery. 

It seems that the router with the IPsec tunnel sends an ICMP need to 
frag packet with the next hop mtu set to 0. This causes ssh to 
retransmit a the same packet without reducing the size of the data payload.


Is this a know problem? If so are there any know work arounds?

Tom

Network Layout:

Box 1 --(lan)-- Router 1 --(lan)-- Router 2 --(Ipsec tunnel)-- Router 3 
--(lan) --- Box 2


Box 1: FreeBSD 5.4
Router [123]: FreeBSD 6.1
Box 2: Linux 2.6



PING Test from box 1 to box 2 with do not fragment set and a packet 
larger than the path MTU:


box1# ping -s 1280 -D box2
PING box2 (10.0.0.79): 1280 data bytes
36 bytes from router1 (172.17.3.5): Redirect Host(New addr: 172.17.3.6)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
4  5  00 051c b454   0   40  01 c9fc 172.17.1.48  10.0.0.79

36 bytes from router2 (172.17.3.6): frag needed and DF set (MTU 0)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
4  5  00 1c05 b454   0   3f  01 cafc 172.17.1.48  10.0.0.79

36 bytes from router1 (172.17.3.5): Redirect Host(New addr: 172.17.3.6)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
4  5  00 051c b45f   0   40  01 c9f1 172.17.1.48  10.0.0.79

36 bytes from router2 (172.17.3.6): frag needed and DF set (MTU 0)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
4  5  00 1c05 b45f   0   3f  01 caf1 172.17.1.48  10.0.0.79

^C
--- box2 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

PING Test from box 1 to box 2 with do not fragment set and a packet 
smaller than the path MTU:


box1# ping -s 1200 -D box2
PING box2 (10.0.0.79): 1200 data bytes
36 bytes from router1 (172.17.3.5): Redirect Host(New addr: 172.17.3.6)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
4  5  00 04cc b472   0   40  01 ca2e 172.17.1.48  10.0.0.79

1208 bytes from 10.0.0.79: icmp_seq=0 ttl=61 time=111.017 ms
36 bytes from router1 (172.17.3.5): Redirect Host(New addr: 172.17.3.6)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
4  5  00 04cc b479   0   40  01 ca27 172.17.1.48  10.0.0.79

1208 bytes from 10.0.0.79: icmp_seq=1 ttl=61 time=110.419 ms
^C
--- box2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 110.419/110.718/111.017/0.299 ms
box1# 




Relevent interface configuration on box1 (from ifconfig):

em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
   options=bRXCSUM,TXCSUM,VLAN_MTU
   inet 172.17.1.48 netmask 0x broadcast 172.17.255.255
   ether 00:0f:1f:fa:d1:b5
   media: Ethernet autoselect (1000baseTX full-duplex)
   status: active



Relevent interface configuration on router2 (from ifconfig):

em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
   options=bRXCSUM,TXCSUM,VLAN_MTU
   inet 172.17.3.6 netmask 0x broadcast 172.17.255.255
   ether 00:c0:9f:12:13:1b
   media: Ethernet autoselect (1000baseTX full-duplex)
   status: active
gif0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1280
   tunnel inet 63.174.175.252 -- 82.195.173.206
   inet 192.168.174.10 -- 192.168.174.9 netmask 0xfffc


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]