Project

General

Profile

Bug #7015

IPsec not working with specific ISP

Added by Renato Botelho 2 months ago. Updated about 1 month ago.

Status:
Confirmed
Priority:
High
Category:
IPsec
Target version:
Start date:
12/16/2016
Due date:
% Done:

0%

Affected version:
2.4
Affected Architecture:

Description

@luiz has the details, looks like a ESP fragment but it creates odd state with unknown IP address like:

enc0 icmp 69.0.0.84:6748 <- 172.27.10.20:6748 0:0

History

#1 Updated by Renato Botelho 2 months ago

  • Priority changed from Normal to High

#2 Updated by Steve Wheeler about 1 month ago

Also seeing this after upgrading to 2.4.

Initially unable to ping across the tunnel but a packet capture showed pings leaving over IPSec and replies coming back. The replies were being blocked in the firewall, not matching the state opened. By adding a rule to pass that reply traffic I am able ping but the state created is indeed very weird:

LAN icmp 172.21.16.5:6442 -> 172.27.34.10:6442 0:0 7 / 6 588 B / 504 B
IPsec icmp 172.21.16.5:6442 -> 172.27.34.10:6442 0:0 7 / 0 588 B / 0 B
IPsec icmp 172.27.34.10:6442 -> 69.0.0.84:6442 0:0 6 / 0 504 B / 0 B

Yet the ping replies are correctly routed back to 172.21.16.5.

Also for UDP traffic:

LAN udp 172.21.16.7:5060 -> 172.27.34.10:5060 MULTIPLE:MULTIPLE 904 / 691 593 KiB / 380 KiB
IPsec udp 172.21.16.7:5060 -> 172.27.34.10:5060 SINGLE:NO_TRAFFIC 904 / 0 593 KiB / 0 B
IPsec udp 172.27.34.10:5060 -> 69.96.2.50:5060 NO_TRAFFIC:SINGLE 648 / 0 356 KiB / 0 B

That VoIP works fine though.

For TCP traffic it appears each state only sees one half of the exchange so both block the out-of-state traffic. I had to add floating rules with direction any, flags any, and sloppy states in order to pass it.

Other users on that same IPSec server hitting the same resources are not seeing this problem. My end point is behind NAT so the tunnel uses NAT-T though.

#4 Updated by Renato Botelho about 1 month ago

Vladimir Putin wrote:

Could it be related to https://redmine.pfsense.org/issues/6937 ?

I believe not. We just found out an evidence this issue only happens when WAN interface is behind NAT

Also available in: Atom PDF