Project

General

Profile

Actions
Copy link

Regression #12834

closed

Only TCP traffic is passed outbound through IPFW

Added by B P almost 3 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Reid Linnemann
Category:
Captive Portal
Target version:
2.7.0
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.05
Release Notes:
Default
Affected Version:
2.6.0
Affected Architecture:
All

Description

As already described in forum the outbound nat is not working for udp packets since upgrading to 2.6.

https://forum.netgate.com/topic/169879/nat-is-not-working-after-upgrade-to-2-6-0

Files

Download all files
IPFW List(Before).png (54 KB) IPFW List(Before).png Before enabling and logging into the captive portal Aspiring Network Admin, 04/28/2022 07:55 PM
IPFW table all list(Before).png (70.7 KB) IPFW table all list(Before).png Before enabling and logging into the captive portal Aspiring Network Admin, 04/28/2022 07:55 PM
IPFW list(After).png (81.9 KB) IPFW list(After).png After enabling and logging into the captive portal Aspiring Network Admin, 04/28/2022 07:56 PM
IPFW table all list(after).png (70.7 KB) IPFW table all list(after).png After enabling and logging into the captive portal Aspiring Network Admin, 04/28/2022 07:56 PM
Rules WAN.png (44.5 KB) Rules WAN.png Still Default Rules Aspiring Network Admin, 04/28/2022 07:56 PM
Rules LAN.png (61.1 KB) Rules LAN.png Still Default Rules Aspiring Network Admin, 04/28/2022 07:56 PM
clipboard-202204291305-sg0eq.png (47.5 KB) clipboard-202204291305-sg0eq.png Aspiring Network Admin, 04/29/2022 12:06 AM
Actions
Copy link
 #1

Updated by Steve Wheeler almost 3 years ago

  • Tracker changed from Bug to Regression
  • Subject changed from Outbound NAT on 2.6 not working for udp traffic when Captive Portal is enabled to Only TCP traffic is passed outbound though IPFW
  • Target version set to 2.7.0
  • Plus Target Version set to 22.05
  • Affected Version set to 2.6.0
  • Affected Architecture All added
  • Affected Architecture deleted (amd64)

This doesn't actually appear to be a NAT issue, the NAT pf states are all created as expected.

Rather it appears the reply traffic is being blocked by IPFW. TCP outbound traffic is passed by the catch all rule we have for that.

00999 332478   21536130 allow tagged 1
01000 911557 1111954968 skipto tablearg ip from any to any via table(cp_ifaces)
01100 799203 1117048984 allow ip from any to any
02100      0          0 pipe tablearg tag 1 MAC table(test_zone_pipe_mac)
02101      0          0 allow pfsync from any to any
02102      0          0 allow carp from any to any
02103      0          0 allow layer2 mac-type 0x0806,0x8035
02104      0          0 allow layer2 mac-type 0x888e,0x88c7
02105      0          0 allow layer2 mac-type 0x8863,0x8864
02106      0          0 deny layer2 not mac-type 0x0800,0x86dd
02107    644      44960 allow ip from any to table(test_zone_host_ips) in
02108    682     257204 allow ip from table(test_zone_host_ips) to any out
02109      0          0 allow ip from any to 255.255.255.255 in
02110      0          0 allow ip from 255.255.255.255 to any out
02111      0          0 pipe tablearg ip from table(test_zone_allowed_up) to any in
02112      0          0 pipe tablearg ip from any to table(test_zone_allowed_down) in
02113      0          0 pipe tablearg ip from table(test_zone_allowed_up) to any out
02114      0          0 pipe tablearg ip from any to table(test_zone_allowed_down) out
02115 166239   10768065 pipe tablearg tag 1 ip from table(test_zone_auth_up) to any layer2 in
02116 370541  550293377 pipe tablearg tag 1 ip from any to table(test_zone_auth_down) layer2 out
02117     15       1770 fwd 127.0.0.1,8002 tcp from any to any 80 in
02118 370571  550297403 allow tcp from any to any out
02119    193      60617 skipto 65534 ip from any to any
65534    768      95525 deny ip from any to any
65535      0          0 allow ip from any to any
Actions
Copy link
 #2

Updated by Jim Pingle almost 3 years ago

  • Assignee deleted (Jim Pingle)
Actions
Copy link
 #3

Updated by Reid Linnemann almost 3 years ago

  • Assignee set to Reid Linnemann
Actions
Copy link
 #4

Updated by Reid Linnemann almost 3 years ago

ipfw is now active on layer 3 where it was not previously on 2.5.2. As a result, there are now additional passes of the chain at layer 3 where the ethernet header is not available. The out direction on the captive portal interface is the troublesome part, because outbound traffic hits the filter on layer 3 first and isn't passed except potentially by the allowed IP list rules. This can be alleviated by adding a "pass all from any to any not layer2" rule prior to rule 1000. Updated rules are forthcoming in the System_Patches package.

Actions
Copy link
 #5

Updated by Reid Linnemann almost 3 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #6

Updated by Jim Pingle almost 3 years ago

You can install the System Patches package and then apply this patch directly from the built-in Recommended Patches list.

The patch is available in the System Patches package version 2.0_4 or later, no need to create a manual entry.

Actions
Copy link
 #7

Updated by B P almost 3 years ago

Maybe i miss something, but after applying the patch i have no connectivity (from captive portal enabled interfaces) at all.
Can somebody confirm this? Maybe it happens because i use mac address bypasses?

Update:

Apply patch > stop captive portal service > disconnect all clients > start captive portal > connect client with mac address bypass > captive portal page opens
Revert patch > stop captive portal service > disconnect all clients > start captive portal > connect client with mac address bypass > works as expected

Actions
Copy link
 #8

Updated by Reid Linnemann almost 3 years ago

You will need to reboot so that all of the ipfw rules are reloaded, have you done so?

Actions
Copy link
 #9

Updated by B P almost 3 years ago

Okay thats completely right. After rebooting everything works as expected. Thank you a lot for fixing this!

Actions
Copy link
 #10

Updated by Reid Linnemann almost 3 years ago

Excellent! I'm glad to know you are back up and running again. Thank you for the confirmation!

Actions
Copy link
 #11

Updated by → luckman212 over 2 years ago

Jim Pingle was this one merged as of 22.05.a.20220331.1603? I'm looking in System Patches under "Recommended System Patches" and it won't apply or revert cleanly. I looked at the code and /etc/inc/captiveportal.inc looks like it's had significant changes.

Actions
Copy link
 #12

Updated by Jim Pingle over 2 years ago

→ luckman212 wrote in #note-11:

Jim Pingle was this one merged as of 22.05.a.20220331.1603? I'm looking in System Patches under "Recommended System Patches" and it won't apply or revert cleanly. I looked at the code and /etc/inc/captiveportal.inc looks like it's had significant changes.

No, there is a different approach being used on 22.05/2.7.0, nothing has changed there yet as the work is still ongoing.

Actions
Copy link
 #13

Updated by Aspiring Network Admin over 2 years ago

Hi Sir may I ask if you already fixed this problem that you have on your Captive Portal? We have the same problem and I already apply 'Fix Captive Portal handling of non-TCP traffic after login' then reboot my pfsense but still don't work.

This is my case Sir.

"I really need help with my issue. I have a Active Directory LDAP and I bind it on my pfsense(Working good) then I configure my Captive Portal on my pfsense.

My problem is after I login my user credentials(LDAP AD) I can't access internet. BUT if I disable my Captive Portal my internet is working good and I can browse any sites.

P.S. My DNS and DCHP is on my window server."

Actions
Copy link
 #14

Updated by Reid Linnemann over 2 years ago

Aspiring Network Admin wrote in #note-13:

Hi Sir may I ask if you already fixed this problem that you have on your Captive Portal? We have the same problem and I already apply 'Fix Captive Portal handling of non-TCP traffic after login' then reboot my pfsense but still don't work.

This is my case Sir.

"I really need help with my issue. I have a Active Directory LDAP and I bind it on my pfsense(Working good) then I configure my Captive Portal on my pfsense.

My problem is after I login my user credentials(LDAP AD) I can't access internet. BUT if I disable my Captive Portal my internet is working good and I can browse any sites.

P.S. My DNS and DCHP is on my window server."

Would you mind posting the output of shell commands 'ipfw list' and 'ipfw table all list' executed from Diagnostics->Command Prompt both before and after you enable and log in to the captive portal? This may shed some more light on your particular case. Please be sure to anonymize any addresses or names in the output that are sensitive.

Also, did you have this configuration working on a previous version of pfSense?

Actions
Copy link
 #15

Updated by Aspiring Network Admin over 2 years ago

Hi Sir Reid thank you for the reply. This is my ipfw list and ipfw table all list before and after enabling and logging into the captive portal.

Please see attached photos Sir.

It's my very first time configuring pfsense Sir.

Before enabling and logging into the captive portal
Before enabling and logging into the captive portal
After enabling and logging into the captive portal
After enabling and logging into the captive portal
Still Default Rules
Still Default Rules

Actions
Copy link
 #16

Updated by Aspiring Network Admin over 2 years ago

Sorry Sir I duplicate the "Ipfw table all list" of after enabling the Captive Portal and the before enabling captive portal is missing. Please see attached photo Sir for the "ipfw table all list" before enabling Captive Portal. Thanks.

Actions
Copy link
 #17

Updated by Reid Linnemann over 2 years ago

I don't see any immediate reason it should not be working, the patch is definitely applied and the pass all not layer2 rule is present. You might have more success with the upcoming 2.7.0 release, which will be stripping out ipfw altogether from the captive portal.

Actions
Copy link
 #18

Updated by Reid Linnemann over 2 years ago

  • Status changed from Feedback to Resolved

Closing, ipfw is out of the mix for 2.7.0/22.05

Actions
Copy link
 #19

Updated by Jim Pingle over 1 year ago

  • Subject changed from Only TCP traffic is passed outbound though IPFW to Only TCP traffic is passed outbound through IPFW
Actions
Copy link

Also available in: Atom PDF