Upgrade from 16.7.14: Firewall rules doesn't works as before

Started by framura, January 31, 2017, 08:18:29 PM

Previous topic - Next topic
just tried Setting

""Use shared forwarding between packet filter, traffic shaper and captive portal"."

reactivates Workarround 

sysctl net.inet.ipsec.filtertunnel=1

Hi,

is there any news on this? I'm using 17.1.3 and still have problems with IPSEC traffic being blocked by the firewall. Is there any workaround (except for possibly creating a hole in the fw by allowing bogus IPs on WAN)?

Quote from: sln on March 19, 2017, 08:41:38 PM
Hi,

is there any news on this? I'm using 17.1.3 and still have problems with IPSEC traffic being blocked by the firewall. Is there any workaround (except for possibly creating a hole in the fw by allowing bogus IPs on WAN)?

I would suggest checking out this thread with a test kernel to try:
https://forum.opnsense.org/index.php?topic=4804.0

Quote from: djGrrr on March 20, 2017, 03:04:17 AM
I would suggest checking out this thread with a test kernel to try:
https://forum.opnsense.org/index.php?topic=4804.0
Thanks for the advise! Sadly this kernel doesn't fix the issue (at least for me) with IPsec traffic getting filtered by the firewall despite rules saying otherwise.

Quote from: sln on March 22, 2017, 12:18:16 PM
Quote from: djGrrr on March 20, 2017, 03:04:17 AM
I would suggest checking out this thread with a test kernel to try:
https://forum.opnsense.org/index.php?topic=4804.0
Thanks for the advise! Sadly this kernel doesn't fix the issue (at least for me) with IPsec traffic getting filtered by the firewall despite rules saying otherwise.

Hey, tried this?
https://forum.opnsense.org/index.php?topic=4313.msg19025#msg19025

I'm currently updating my 12 FW's for my company and only this solution works for me.

Hi all,

I have the same problem with 17.1.6.

00:00:00.000000 rule 88/0(match): pass in on igb2: 192.168.11.23.64782 > 172.18.210.10.443: Flags , seq 3434102374, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
00:00:00.000080 rule 77/0(match): pass out on enc0: 192.168.11.23.64782 > 172.18.210.10.443: Flags , seq 3434102374, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
00:00:00.023806 rule 12/0(match): block in on enc0: 172.18.210.10.443 > 192.168.11.23.64782: Flags [S.], seq 4228346538, ack 3434102375, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
00:00:03.003031 rule 12/0(match): block in on enc0: 172.18.210.10.443 > 192.168.11.23.64782: Flags [S.], seq 4228346538, ack 3434102375, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
00:00:06.006306 rule 12/0(match): block in on enc0: 172.18.210.10.443 > 192.168.11.23.64782: Flags [S.], seq 4228346538, ack 3434102375, win 65535, options [mss 1460,nop,nop,sackOK], length 0
00:00:11.996356 rule 12/0(match): block in on enc0: 172.18.210.10.443 > 192.168.11.23.64782: Flags [R], seq 4228346539, win 0, length 0

I tried the floating roule but the issue persist. The ICMP working fine but TCP/UDP will be blocked by PF.


Regards,
Liberomic

Hi All,

we have replicated the configurations on different site and the issue persist.
The difference between my office site to datacenter where the IPSEC workingfine and two branch office, the wan interfaces is NATed.

Regards,
Liberomic

   

Hi Franco,

I have found this workaround, but would not be permanent (if I will change a firewall rules... restart the appliance... this rules will be deleted).

I have deleted this line from /tmp/rules.debug
block in  log inet from {any} to {any} label "Default deny rule"
block in  log inet6 from {any} to {any} label "Default deny rule"

I have added this line at the end of file  (all interface without IPSEC "enc0")

block in  log on $WAN inet from {any} to {any} label "Default deny rule"
block in  log on $WAN inet6 from {any} to {any} label "Default deny rule"
block in  log on $LAN inet from {any} to {any} label "Default deny rule"
block in  log on $LAN inet6 from {any} to {any} label "Default deny rule"

# pfctl -f /tmp/rules.debug

Do you have a solution for this PF issue?

Many thanks for your support.  :'( :'( :'(

Liberomic

Hi all,

I have checked in 17.1.7 and the issue persist.

Regards,
Liberomic

What's your rule on the IPsec tab? Isn't it easier to use any -> any there?

Hi Franco,

on IPSEC interface we have checked all combinations.

ANY--ANY--Accept
SurceVPN subnet--Local subnet--Accept

But the issue persist......

I have replicated the issue on different site and this issue will be replicable.

To clarify the issue I am writing network scheme, I have four site connected by IPSEC to central Office (HO).

- Office1 (opnsense) to Head Office: in this site working fine the wan interface of opnsense is Public IP
- Office2 (opnsense) to Head Office: I have WAN interface NATed and the inbound traffic will be blocked on enc0 interface
- Office3 (opnsense) to Head Office: I have WAN interface NATed and the inbound traffic will be blocked on enc0 interface

for Office2 and Office3 I have applyed my workaround for inbound traffic coming from Head Office, because without my workaround working only ICMP traffic and TCP/UDP will be blocked.

Note: on Office2 and Office3 I have enabled Nat Traversal and the router forward all ports to opnsense WAN interface. I have upgraded all opnsense to 17.1.7.

Thanks for your support
Liberomic






Hi All,

do you have news for this PF issue?

Regards,
Liberomic

Hi,

i have the same issue, since 17.1.1 no Roules for IPSEC trigger (now actual 17.1.8). I try all the hints, but nothing works for me.

Is there any news about this topic?

Regars
Sven

Hi All,

this issue is very bad, with my workaround the incoming traffic working fine....
But this change in the file /tmp/rules.debug will be lost, when you modify firewall rules or restart the appliance....

Regards,
Liberomic