IP or MAC passthrough didn't work

dikkie21

Passthrough MAC addresses and IP addresses on the Captive Portal...

Gertjan

There might have been some issue with an client version .... I don't recall what it was.
But your not saying what pfSense version you use, so I can't tell more.

What I can say : use the latest : 23.05.
That works, and I'm sure, as I just tested it;

I selected my captive portal wifi : I had to authenticate.
I didn't do so.
I added my phone's MAC to the list :

I selected my captive portal wifi : no need to authenticate - I was connected - no limits (TCP, UDP, ICMP, whatever, but only IPv4, of course).

net-mas

Hello, I have the same problem. The IP address passthrough went for years. I upgraded from CE to v23.05 last week. Since then, the settings under Captive Portal - allowed IP addresses are no longer used by the system.

I noticed that I allowed both directions in the settings, but in contrast to before, the two double arrows in the overview of the allowed IP addresses are no longer visible.

The same effect can be seen under allowed hostnames. At least old host names are still there with a double arrow on the left in the overview, but newly added host names with permitted directions both no longer have double arrows.

even if I set the direction to "from" or "to", double arrows no longer appear in the overview list.

what can I do so that the permitted IP addresses bypass the captive portal registration again and are not always directed to the captive portal registration mask after 1 hour?

even deleting an entry from PfSense CE and creating it again in PFSense+ 23.05 does not change anything. The entry "Allow in both directions" is saved, is also visible when the entry is called up again, but is apparently not used (anymore) in the system.

FSC830

@net-mas : at least at a NetGate appliance SG-3100 the entry works.

The appliance new installed with 22..05 and updated -> 23.01 -> 23.05.

Regards

net-mas

@FSC830 :
I have created a new captive portal "test" and released an IP address in it. Unfortunately it does not work.
In contrast to your appliance, my PFSense has only been upgraded from CE to 23.01 to 23.05.

`

what can I do?

FSC830

Strange, but my guess its an individual issue.
I just updated my test VM to 23.05 and it works:

The entry was just created.
History of this VM is v2.6.0 CE -> 22.05-> 23.01 -> 23.05.

May be someone else has an idea...

Regards

dikkie21

We were still running on pfSense CE version 2.0.6. After an upgrade to pfSense+ 23.05 the problem is solved! Finally after 1.5 years!!

Thanks for helping and the right suggesion!

net-mas

Unfortunately I still have the problem. I don't know what to do here. I can't fix it. No matter what I do, I don't get the two arrows to the left of the line and the entries don't work either. Apart from the update from CE to 23.05 nothing has changed. I urgently ask for help.

Gertjan

@FSC830 said in IP or MAC passthrough didn't work:

May be someone else has an idea...

More a suggestion.

What about the manual ? There is one called "Troubleshooting Captive Portal".
Only valid for pfSense+, I guess, as "2.6.0 CE" still uses the now abandoned ipfw firewall.

This command :

pfSsh.php playback pfanchordrill

shows a lot.
If an IP or MAC isn't listed : normal that 'it' doesn't work.

Also, Diagnostics > Limiter Info should show a Limiter and scheduler for every connection.
2.6.0 had an issue with that, but, if I recall well, the system patches packages resolved that.

Btw : what is 172.18.1.128 ? It isn't RFC1918 .... (is it ?) - Can't route to it.

host names are like aliases, and regularly refreshed (== resolved, as a firewall can't use host names, only IPs) - you should be able to resolve theme manually : Diagnostics DNS Lookup
These host names should resolve to just one ( 1 ) IPv4.

My captive portal - I removed all connectd users.
There are no "allowed host names"
No MAC's ...
3 "Allowed IP Addresses" : 192.168.2.2 - 192.168.2.3 - 192.168.2.4, these are my AP, so they can do their stuff on the Internet (mostly NTP and syslogging to a syslog server on my LAN).

[23.05-RELEASE][root@pfSense.local.tld]/root: pfSsh.php playback pfanchordrill

cpzoneid_2_allowedhosts rules/nat contents:

cpzoneid_2_allowedhosts/hostname_0 rules/nat contents:
pfctl: DIOCGETETHRULES: No such file or directory

cpzoneid_2_allowedhosts/192.168.2.2_32 rules/nat contents:
ether pass in quick proto 0x0800 l3 from any to 192.168.2.2 tag cpzoneid_2_auth dnpipe 2000
ether pass in quick proto 0x0800 l3 from 192.168.2.2 to any tag cpzoneid_2_auth dnpipe 2001

cpzoneid_2_allowedhosts/192.168.2.3_32 rules/nat contents:
ether pass in quick proto 0x0800 l3 from any to 192.168.2.3 tag cpzoneid_2_auth dnpipe 2002
ether pass in quick proto 0x0800 l3 from 192.168.2.3 to any tag cpzoneid_2_auth dnpipe 2003

cpzoneid_2_allowedhosts/192.168.2.4_32 rules/nat contents:
ether pass in quick proto 0x0800 l3 from any to 192.168.2.4 tag cpzoneid_2_auth dnpipe 2004
ether pass in quick proto 0x0800 l3 from 192.168.2.4 to any tag cpzoneid_2_auth dnpipe 2005

cpzoneid_2_allowedhosts/hostname_0 rules/nat contents:
pfctl: DIOCGETETHRULES: No such file or directory

ipsec rules/nat contents:

natearly rules/nat contents:

natrules rules/nat contents:

openvpn rules/nat contents:

tftp-proxy rules/nat contents:

userrules rules/nat contents:

cpzoneid_2_allowedhosts rules/nat contents:

cpzoneid_2_allowedhosts/hostname_0 rules/nat contents:
pfctl: DIOCGETETHRULES: No such file or directory

cpzoneid_2_allowedhosts/192.168.2.2_32 rules/nat contents:
ether pass in quick proto 0x0800 l3 from any to 192.168.2.2 tag cpzoneid_2_auth dnpipe 2000
ether pass in quick proto 0x0800 l3 from 192.168.2.2 to any tag cpzoneid_2_auth dnpipe 2001

cpzoneid_2_allowedhosts/192.168.2.3_32 rules/nat contents:
ether pass in quick proto 0x0800 l3 from any to 192.168.2.3 tag cpzoneid_2_auth dnpipe 2002
ether pass in quick proto 0x0800 l3 from 192.168.2.3 to any tag cpzoneid_2_auth dnpipe 2003

cpzoneid_2_allowedhosts/192.168.2.4_32 rules/nat contents:
ether pass in quick proto 0x0800 l3 from any to 192.168.2.4 tag cpzoneid_2_auth dnpipe 2004
ether pass in quick proto 0x0800 l3 from 192.168.2.4 to any tag cpzoneid_2_auth dnpipe 2005

cpzoneid_2_allowedhosts/192.168.2.2_32 rules/nat contents:
ether pass in quick proto 0x0800 l3 from any to 192.168.2.2 tag cpzoneid_2_auth dnpipe 2000
ether pass in quick proto 0x0800 l3 from 192.168.2.2 to any tag cpzoneid_2_auth dnpipe 2001

cpzoneid_2_allowedhosts/192.168.2.3_32 rules/nat contents:
ether pass in quick proto 0x0800 l3 from any to 192.168.2.3 tag cpzoneid_2_auth dnpipe 2002
ether pass in quick proto 0x0800 l3 from 192.168.2.3 to any tag cpzoneid_2_auth dnpipe 2003

cpzoneid_2_allowedhosts/192.168.2.4_32 rules/nat contents:
ether pass in quick proto 0x0800 l3 from any to 192.168.2.4 tag cpzoneid_2_auth dnpipe 2004
ether pass in quick proto 0x0800 l3 from 192.168.2.4 to any tag cpzoneid_2_auth dnpipe 2005

cpzoneid_2_auth rules/nat contents:

cpzoneid_2_passthrumac rules/nat contents:

I guess "DIOCGETETHRULES" means : it's reboot time.

Not sure why the same line "ether pass in quick proto 0x0800 l3 from any to 192.168.2.2 tag cpzoneid_2_auth dnpipe 2000" is listed 3 times ....

This instance is running :

46557  -  Is       0:00.01 /usr/local/sbin/filterdns -p /var/run/filterdns-cpzone1-cpah.pid -i 300 -c /var/etc/filterdns-cpzone1-captiveportal.conf -d 1

But where is the resolved IP ?
Hummmm.

For now : my advice : if needed : use the IP, not the host name.

net-mas

@Gertjan
Thanks for your Support.
I tested. My cell phone is in the IP subnet, which should go past the captive login mask. It still got the login mask. Here is the relevant output of your command:

cpzoneid_2_auth/172.18.7.152_32 rules/nat contents:
ether pass in quick proto 0x0800 l3 from 172.18.7.152 to any tag cpzoneid_2_auth dnpipe 2050
ether pass out quick proto 0x0800 l3 from any to 172.18.7.152 tag cpzoneid_2_auth dnpipe 2051
her is complete Output.txt

to your other question, I have two IP networks for the clients, 172.18.7.0/25 for clients with a login mask and 172.18.7.128/25 for clients without a login mask.
and that for different subnets - i.e. two WLANs - one as a guest WLAN without a key, the other as a WLAN with a key but without a login mask

net-mas

My problem is that since the update to PFSense+ I can no longer record "positive entries" and the existing entries are no longer accepted.
In the detailed view I allow the IP addresses in both directions, but this is not shown in the overview.

The double arrows are missing and it is not used

I can also set the direction from "both" to "from" or "to", the result is the same - no arrows appear in the overview and the entry is also ignored - i.e. does not work. This happens with allowed IP addresses and allowed host names. With one small difference - with the allowed host names, entries before the update to PFSense+ still work, only new entries are created without arrows. With the permitted IP addresses, both the old addresses and the new ones no longer work.
See also my screenshots above.
This circumstance is also the case when I set up a completely new captive portal. I don't know what to do here.

Gertjan

@net-mas

Allowed IP Address is an IP address - not a network (/25).

net-mas

@Gertjan : with PFSense CE networks. I can also record a network.
As you can see, there is an IP address at the bottom - this doesn't work either.
IP addresses can also be recorded in a new, empty captive portal, but they do not work because there are no arrows in the overview.
In the screenshot of the entry mask, it is also clearly visible at the top right that it is possible to enter subnets.
The whole thing doesn't work in allowed host names either.
This hint is nice, but I don't think it will be the cause.

Gertjan

@net-mas

2.6.0 is ipfw based, a firewall that doesn't exists anymore.
I advise you to test drive the upcoming 2.7.0, as it is close to release now.

It will take care of any MAC / IP pass though issues.

On the other hand : I was using 2.6.0 for a long time, and I needed the portal as I needed it for a hotel.
When 2.6.0 came out, I had some issues, but was resolved very soon. All details are here in the forum.
I always had some IP pass throughs for my APs, and some MAC passes, they worked.
But trying to work with /25 - I never did that.

net-mas

@Gertjan
Thank you for your support. I have now rolled back to version 2.6.0 (reinstalling, reinstall PfBlockerNG and restoring AutoConfigBackup with a version before the update).
Now everything works again as desired.
When 2.7.0 is released, I will update there and see what else is possible after that.

What I did notice, however, was that the double arrows were again in front of the allowed IP entries, but when I added a single additional allowed IP as a test, all double arrows disappeared. However, all entries apply and are processed correctly.
There is a similar behavior with the allowed host names. All entries have the double arrows but as soon as I add one, it no longer has the arrows in the list. However, the existing double arrows remain until I open the entry once and close it again without making any changes.
The whole thing is definitely a bug that was added with an unspecified release, but my attempt to officially report this bug was unfortunately dismissed as a configuration problem. So I don't even know how to report bugs like this if the developers don't think it's a bug. It's really a pity... I can only hope that other users will notice this too, so that it might be recognized as a bug and eliminated.

But a freshly set up 2.6.0 system with an official config restore can't be a configuration error for my taste...

susobaco

@net-mas Hello, I think I have a similar problem.
link text

net-mas

@susobaco
I answered you in your post. Please create a bug yourself - maybe you can better convey to the developers with your words that it is a regression of this current firmware.
Then note the device key under "AutoConfigBackup" and reinstall to 2.6.0 and restore a config from 2.6.0 with the device key. Then we'll be right back.
Let's hope that the developers will adjust the firmware and get the captive portal up and running again.