IPSec outbound traffic being blocked on IPSec interface
-
I understand that's right.
I thought it would be useful for solving bugs -
Is there a workaround?
-
Add some very forgiving floating rules outbound on enc0 that allow any TCP flags and use sloppy state.
-
Thanks jimp! You are the best.
-
Add some very forgiving floating rules outbound on enc0 that allow any TCP flags and use sloppy state.
Any idea how to do so? sloppy state how to set this?
Also I don't see enc0 only see lan wan and ipsec interface. -
See attached. This one will be in Firewall->Rules->Floating->Add/Edit
-
@w0w:
See attached. This one will be in Firewall->Rules->Floating->Add/Edit
Thank you so much! It's all working now.
Still would be good to see 2.4 working without work around …
-
Anyone seeing this if you check the states created for traffic across the VPN do you see odd destination IPs?
Such as shown here: https://redmine.pfsense.org/issues/7015
And if so what type of VPN are you using? Mobile IPSec? NAT-T? Helpful to narrow down the cause here.
Steve
-
Steve, I have mobile IPSEC running.
When I looked at Diagnostics/States/States, then the first thing that I have found is that I can not select IPSEC as interface just because it's not listed in the drop down menu, but if I select 'all' I see IPSEC in the list and it's full of odd IP's, there are a lot of them. -
Yup, I noted that while doing exactly this. Jimp added it: https://github.com/pfsense/pfsense/commit/c1f1072e147e2b77fc1bbf7d6230267b9d340c83
Steve
-
Steve
I'm using on NAT-T
The WAN interface is behind NAT
Written by jimp
–---
Add some very forgiving floating rules outbound on enc0 that allow any TCP flags and use sloppy state.Registering floating while looking at errors that occur every time you communicate, such as SMB and RDP, was hard work
After enabling System / Advanced / Firewall & NAT / Disable Firewall, VPN communication was done without registering a floating
It is possible because the WAN interface is behind NAT
ysdtkhr
-
Yes, this does seem to be caused by or a symptom of the WAN being behind NAT.
Progress on this will be reported on the bug: https://redmine.pfsense.org/issues/7015
Steve
-
Looks like it fixed on latest snapshot.
-
Great, thanks for the feedback. :)
Steve
-
Working for me too! :D
-
I'm seeing symptoms like those described in this thread with IPv6. I'm trying to use an IPv6 Phase 2 in an IPv4 Phase 1 which uses NAT-T. I'm trying to send all incoming LAN traffic out through a remote VPN server.
The IPv6 states appear to be backwards and all outgoing IPv6 is being blocked by:
block in log inet6 all tracker 1000000105 label "Default deny rule IPv6"Creating a "sloppy floating rule" like the one mentioned earlier in this thread helps somewhat, but traffic still stalls, especially if I take any action that reloads the filters.
I'm new to IPsec so it could be user error, but IPv4 seems to be working fine over the same Phase 1 without any added rules.
-
I'm seeing symptoms like those described in this thread with IPv6. I'm trying to use an IPv6 Phase 2 in an IPv4 Phase 1 which uses NAT-T. I'm trying to send all incoming LAN traffic out through a remote VPN server.
Are you running 2.4? If not, try 2.4. If you are on 2.4, make sure you are on a current snapshot.
If this is still a problem on a current 2.4 snapshot, comment on https://redmine.pfsense.org/issues/7015 with the details of your IPsec setup, firewall rules, and state table contents.
-
I'm running 2.4.0.b.20170403.0902.
I'll gather some details for that bug.
Thanks.
-
Hello,
I have the same problem, I have 3 PFsense (A, B, C) in IPSEC VPN site-to-site.
Until version 2.3.6 everything worked perfectly. Just after upgrading to Version 4, Site C only passes PING but no TCP / UDP service.The strange thing is that A and B work perfectly.
I reset the configuration of C (2 HP DL160Gen9 Server in HA) and tried to create a local VPN between C1 and C2 with version 2.3.6 and it works perfectly. Just updating to version 2.4 works only on PING.
I think it is a bug that only affects some hardware with version 2.4. -
Hi,
Not sure if it's related, but I saw similar state weirdness. IKEv2 mobile clients, with clients behind nat, but server with public IP. IPv4 only.
In my case the trigger seemed to be multiple clients with the same credentials, when I had peer identifier set to any, and configure unique IDs = yes. I saw similar unidirectional TCP issues as well.
