Poor IPSec performance
-
Is this just a test or is this a prod enviroment? Why are you directly connecting the 2 pfSense boxes to each other? is this a point2point tunnel? Do you want internet requests to go through the IPSEC tunnel? Have you tried specifying the correct subnet rather than 0.0.0.0/0? Did you modify the Outbound NAT? You might be having a conflict with the built-in NAT trying to send anything not specified out the WAN rather than the ipsec tunnel.
-
It is suppose to go in the production environment.
The 2 pfsense boxes are connected via a L2 connection with the soul purpose of encrypting all traffic between them.
I have tried only having the 172.16.10.0/24 net behind pfs2 and only 172.16.100.0/26 behind pfs1. With requests from one net to the other icmp goes through. No problem. I can telnet through. But if I do a "show log" on the switch I'm telnetting to it briefly starts and then comes to a halt. This is also true if I connect to a windows share. A small amount of traffic is being sendt and the nothing.
Again all works without IPSec.
Modyfied::
I should also menthion that all packet filtering and NAT is turned off.
I was thinking about "Bypass firewall rules for traffic on the same interface", " Block RFC1918 Private Networks" and "Block bogon networks:" options. Can they play a part?
-
Another discovery I made right now is that when ever the length of an ESP packet is 1480 everything stops. The next line in a tcpdump is always a esp (in lower case). See also print out.
Can it be the MTU in IPsec?
13:00:47.407446 IP 192.168.42.2 > 192.168.42.1: ESP(spi=0x01e083a4,seq=0x3), length 1480
13:00:47.407450 IP 192.168.42.2 > 192.168.42.1: esp -
I have now performed a ping test where I tried to increase the packet size. When a packet must be fragmented the problem appears.
Does this make sense?
Modifyed::
The max packet size I can ping with and get an answer is 1410. This results in a ESP packet of 1476. Anything larger than that, results in a ESP packet of 1480 and no data is coming through.
tcpdump -vv
Does not go through:
13:19:19.391590 IP (tos 0x0, ttl 64, id 21771, offset 0, flags [+], proto ESP (50), length 1500) 192.168.42.1 > 192.168.42.2: ESP(spi=0x045c0bdd,seq=0xa), length 1480
13:19:19.391593 IP (tos 0x0, ttl 64, id 21771, offset 1480, flags [none], proto ESP (50), length 32) 192.168.42.1 > 192.168.42.2: espGoes through:
13:19:23.807651 IP (tos 0x0, ttl 64, id 49629, offset 0, flags [none], proto ESP (50), length 1496) 192.168.42.1 > 192.168.42.2: ESP(spi=0x045c0bdd,seq=0xb), length 1476 -
Perhaps a "esp_frag 552;" in the racoon.conf will help on this issue but I don't know how to add it to that conf file permanent. Every time I reload racoon the line disappears from the conf file.
Does anyone know if " esp_frag 552;" will help on this issue?
-
Does anyone have any idea on how to fix this issue?
-
Could you upgrade to 1.2.3 http://blog.pfsense.org/?p=377
-
Sure. How do I get a hold off it?
-
http://snapshots.pfsense.org/FreeBSD7/RELENG_1_2/
-
Upgraded to 1.2.3 with no success. Still the same problem :-[
Can it be a HW failure or HW incompatibility?
I've tried a cross-over cable between the two servers with 1000baseTX. I've tried to force the interfaces to 100baseTX with no success and I've tried placing a switch in between. All with the same result.
-
did that racoon config helped you ?
It seems like pmtu discovery problem. Can you take an tcpdump output file of 1min of traffic and attach here either on the enc0 interface and LAN and wan ones -
I was not able to make the changes to the racoon config. It's overwriten every time racoon starts.
I will make a tcpdump asap and attach it here.
-
Here is the dump from the wan interface on pfs1.
I'm not getting any packages on enc0.
I've updated both boxes to 1.2.3 20090224-0050
-
Has anyone any idea?
-
Commercial support might be the way to go
-
Hi Olejak,
have you resolved the problem?
Just interesting…
Actually it is normal for large packets:
13:00:47.407446 IP 192.168.42.2 > 192.168.42.1: ESP(spi=0x01e083a4,seq=0x3), length 1480
13:00:47.407450 IP 192.168.42.2 > 192.168.42.1: espI am just wondering whether you receive the same two packets on the other end? I.e. if it is a trace from FW1 do you see the same packets on FW2?
-
Try placing a switch between the 2 pfSense servers. I ran into issues using crossover cables that were cleared up when I used a gig switch instead.
-John
-
Set the MTU of your adapters down to 1400 and try again. Large packets + IPSEC + no fragmentation is a common problem.
For Windows, you can use this: http://www.dslreports.com/drtcp
-
For Windows, you can use this: http://www.dslreports.com/drtcp
Sounds very interesting. Could you explain in more details? -)
-
Can you please give me a little me details. I have setup a similiar configuration. I had a dual 866 with 1 gb of ram connected over 100 mb connected to compac dl 380 with 100 nics. no speed issues. Teested with serveral different issues.
RC
