Poor IPSec performance

olejak

I have 0.0.0.0/0 liste because I want all traffic encrypted between the two pfsense machines.

kapara

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.

olejak

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?

olejak

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

olejak

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: esp

Goes 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

olejak

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?

olejak

Does anyone have any idea on how to fix this issue?

Perry

Could you upgrade to 1.2.3 http://blog.pfsense.org/?p=377

olejak

Sure. How do I get a hold off it?

Perry

http://snapshots.pfsense.org/FreeBSD7/RELENG_1_2/

olejak

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.

eri--

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

olejak

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.

olejak

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

em1_dump.txt

olejak

Has anyone any idea?

Perry

Commercial support might be the way to go

Eugene

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: esp

I 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?

jftuga

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

valnar

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

Eugene

@valnar:

For Windows, you can use this: http://www.dslreports.com/drtcp

Sounds very interesting. Could you explain in more details? -)