Project

General

Profile

Actions

Bug #1841

closed

TCP state issue when traffic passing through a GRE tunnel within IPSEC

Added by Nigel Wright about 13 years ago. Updated about 9 years ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
Interfaces
Target version:
-
Start date:
09/06/2011
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:

Description

When running a GRE tunnel between two Pfsense 2.0 RC3 TCP traffic is shown as having its SYN/ACK packets dropped on the returning firewall.
This has been established in two scenarios.

Scenario 1 GRE tunnel between WAN interfaces, IPSEC in transport mode between the two WAN interfaces. Ping works fine TCP sessions have SYN/ACK packets dropped on the returning firewall. When IPSEC is disabled everything works fine.

Scenario 2 IPSEC tunnel between LAN interface addresses, GRE tunnel bound to LAN interface. Ping works fine TCP SYN/ACK packets dropped on return.


Files

Pfsense_GRE.zip (121 KB) Pfsense_GRE.zip Nigel Wright, 02/27/2012 05:10 PM
Actions #1

Updated by Chris Buechler about 13 years ago

  • Category set to Interfaces
  • Target version deleted (2.0)
Actions #2

Updated by Jim Pingle over 12 years ago

  • Status changed from New to Feedback

Is this happening on 2.0.1? Does it happen only with GRE or also with GIF?

We have a few people running with that sort of config and I don't recall seeing any issues like this in the process, but I think most of the ones I saw were using GIF, not GRE.

Actions #3

Updated by Nigel Wright over 12 years ago

It's still happening in 2.0.1. I've just set up a test bed, two sites Site A and Site B each with a pfsense firewall with a link between them. With only GRE tunnel established it's possible to ping from site A to site B and telnet from a server in site A to the server in Site B as seen in a packet capture (GRE_ONLY_WAN.cap).

With IPSEC enabled in transport mode between the two firewall WAN IPs pinging from the site A server to the Site B server works fine but telnet no longer does. The screenshot SITE_B_SVR-2012-02-27-22-06-58.png shows the site B firewall rejecting the TCP:SA syn ack packets and the TELNET_Reject.cap shows the return packets coming from the site B server and the firewall responding with a destination unreachable.

The two firewall configs are also included.

I've not tried it with GIF interfaces only with GRE.

Actions #4

Updated by stephane stephane over 12 years ago

I've got exactly the same issue. The main reason for me to use this configuration, is to be able to have VPN and dynamic routing protocol between multiple sites.

Actions #5

Updated by Colin Petrie over 12 years ago

I have the same problem as well, over gif tunnels as well as gre.

I use IPSEC transport mode between the CARP WAN IPs of pfsense pairs at each end. Then have a PtP Gif or Gre on top of that, and then use either static routes or OSPF down the tunnel.

Pings work fine, but again TCP SYN/ACK packets dropped on return.

Actions #6

Updated by Colin Petrie over 12 years ago

Sorry, should have mentioned, both pairs of firewalls are running 2.0.1

Actions #7

Updated by Martin Saini over 12 years ago

Hi! Have setuped the same config - same issue here :( soo is there any "manual" workaround to that?

Actions #8

Updated by Colin Petrie over 12 years ago

Martin Saini wrote:

Hi! Have setuped the same config - same issue here :( soo is there any "manual" workaround to that?

I managed to get ours working by adding a 'floating' rule in the web interface. We have an allow all rule already on the GRE interface, but the state tracking seemed broken on this, I found a hint somewhere saying to add an allow all 'floating' rule, with interface set to the GRE interface, and direction set to any. Also, note that both the rule on the GRE interface, and the floating rule have advanced option 'State Type' set to 'none'.

looking at the generated pf rules, the following two rules result from this:
pass quick on gre0 all no state label "USER_RULE: Allow all traffic over xxxx"
pass in quick on gre0 all no state allow-opts label "USER_RULE: Allow all internal xxxx traffic"

The first rule us the floating rule, it seems to be the one that makes it work. So I guess there's something funny about it that make the direction (in) bit on the second rule be insufficient.

Hope this helps

Actions #9

Updated by Martin Saini about 12 years ago

Hi! Thanks for the info - i will configure that as in one of my next projects, as i have to configure some tunneling stuff with fortinet and cicso. in the meantime i was using openvpn between pfSense Firewalls!

thx alot
m.

Actions #10

Updated by Chris Buechler about 9 years ago

  • Status changed from Feedback to Duplicate
  • Affected Version deleted (2.0)

duplicate of #4479

Actions

Also available in: Atom PDF