Regression #12834
closed
Only TCP traffic is passed outbound through IPFW
Added by B P about 2 years ago. Updated 10 months ago.
100%
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
| 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 |
Updated by Steve Wheeler about 2 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
Updated by Reid Linnemann about 2 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.
Updated by Reid Linnemann about 2 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 225f86af947822e6bd6f816f6b8fa926c34fe857.
Updated by Jim Pingle about 2 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.
Updated by B P about 2 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
Updated by Reid Linnemann about 2 years ago
You will need to reboot so that all of the ipfw rules are reloaded, have you done so?
Updated by B P about 2 years ago
Okay thats completely right. After rebooting everything works as expected. Thank you a lot for fixing this!
Updated by Reid Linnemann about 2 years ago
Excellent! I'm glad to know you are back up and running again. Thank you for the confirmation!
Updated by → luckman212 about 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.
Updated by Jim Pingle about 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.
Updated by Aspiring Network Admin almost 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."
Updated by Reid Linnemann almost 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?
Updated by Aspiring Network Admin almost 2 years ago
- File IPFW List(Before).png IPFW List(Before).png added
- File IPFW table all list(Before).png IPFW table all list(Before).png added
- File IPFW list(After).png IPFW list(After).png added
- File IPFW table all list(after).png IPFW table all list(after).png added
- File Rules LAN.png Rules LAN.png added
- File Rules WAN.png Rules WAN.png added
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.
.png "Before enabling and logging into the captive portal")
.png "Before enabling and logging into the captive portal")
.png "After enabling and logging into the captive portal")
.png "After enabling and logging into the captive portal")
Updated by Aspiring Network Admin almost 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.
Updated by Reid Linnemann almost 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.
Updated by Reid Linnemann almost 2 years ago
- Status changed from Feedback to Resolved
Closing, ipfw is out of the mix for 2.7.0/22.05
Updated by Jim Pingle 10 months ago
- Subject changed from Only TCP traffic is passed outbound though IPFW to Only TCP traffic is passed outbound through IPFW