Can't access PPPOE/ADSL modem from pfSense
-
@stephenw10
Modem's web interface IP was set via the modem's internal interface.
It has options to set an IP and subnet mask (I chose the mask 255.255.255.0) for local access.I tested the modem was reachable by direct ethernet connection (modem <> computer), and manually set the computer's IP/subnet to be on the same network as the modem (tested with both modem interface set 192.168.1.1, and when changed to 10.27.1.1).
Computer could reach the modem interface without issue, based on configuring its IP/subnet manually to conform to the modem's network.I also checked that I was truly getting a PPPoE connection from the modem, by configuring the computer to dial out via PPPoE - and computer reached the internet with no issues.
With interface set, and NAT rule in place:
Pinging modem via Diagnostics>Ping - 0% packet loss
Pinging modem via terminal/command prompt on multiple different computers - 100% packet loss -
Ok. Try again from Diag > Ping in pfSense but set the source as the LAN interface.
That will test the outbound NAT rule but not any firewall rules. So if that works look for a bad or missing firewall rule on the LAN.
If you can post screenshots of your LAN firewall rules and outbound NAT rules we can review them.
Steve
-
Ok. Try again from Diag > Ping in pfSense but set the source as the LAN interface.
If you can post screenshots of your LAN firewall rules and outbound NAT rules we can review them.
ModemAccess interface setup included for completeness.
Note: ALL the PIA and PS4 Pro rules were added long after all my testing for ModemAccess.
None of the IPs involved in those rules include any computer I have tested access to the modem interface from.I had tested both Manual Outbound NAT (per the guide) and Hybrid Outbound NAT, and neither worked. I left it on Hybrid, as I believe this will at least will allow for any possible automatic rules to be setup if I add any other VPN connections.
-
Ok, what IP are you testing from that fails?
Is it in the PIA_route_chicago alias?If it is then you will need a more specific rule above that to pass the traffic to the modem without policy routing it over the VPN. That's probably what's happening there.
Steve
-
@stephenw10
I have tested access to the modem from 10.27.27.2, 10.27.27.3, and10.27.27.150. All of these are Statically DHCP mapped.
None of these are in the PIA_ROUTE_CHICAGO (re-verified before posting this). I confirmed that the computers get my public ISP IP when I test on a whatsmyip website, and it does.
I ensured also that a computer in the PIA_ROUTE_CHICAGO alias gets my VPN IP, and it does.I previously tested ModemAccess from DHCP-assigned (i.e. non-static mapped) computers, before I ever setup the PIA_ROUTE_CHICAGO or the static DHCP mappings (i.e. vanilla pfSense install) , and none of the computers could reach the modem's interface.
-
Hmm, I would expect that to work.
Can those hosts ping the modem?
If they can then try testing against the modem web port from Diag > TestPort.
Assuming it's https make sure you can connect on port 443 successfully from the default source. Then change the source to LAN and retest.
If that succeeds but clients still fail I would be looking at the state table when you are trying to make sure the correct states are opened on LAN and MODEMACCESS.
Steve
-
@stephenw10
Well this is both bizarre, and welcomed...I wanted to re-verify that the modem access IP was indeed what I had been saying, and that nothing could possibly have been altered by the ISP (doubtful, but had to eliminate it).
I reconnected a computer <> modem.
Checked the IP address for the modem web interface.
On confirming it was still the same, I reconnected modem to pfSense router, and voila...
Modem web interface was accessible from all devices.Nothing at all was changed in any settings for modem or pfSense router.
Perhaps the unplug/replugging action for the modem<>pfSense router connection reset the state tables, or enforced rules.
(edited due to next post)
-
Update: It WAS accessible, and now it is not.
And nothing has changed in any cabling, or alterations to modem interface settings or pfSense settings, since mentioning earlier I did get access.
@stephenw10 I'll investigate further what you mentioned in your last posting.
-
Hmm, that sort of timing 'feels' like an ARP issue. But if the modem or pfSense was not responding to ARP correctly they would not be able to ping each other. Check the ARP table in pfSense anyway though.
Maybe a bad subnet mask somewhere? Seems unlikely though.
Steve
-
@stephenw10
I know for sure my modem's internal interface does not require (or work with) https for access. http only.State table
ARP Table entries.
I confirmed these were the only mentions in the table, for either MODEMACCESS or 10.27.1.x :
-
@stephenw10
And today, now it's all just....working.No issues with access anywhere that is not a device assigned into my VPN alias (I never expected them to work though) - and I have tested this at various times throughout the day, with variant workloads, to be sure that something errant wasn't what was causing issues, by firing up and blocking access.
No changes made to configs. Nothing has reset.
Thus, I am both baffled and gratified.I'll work on seeing if there's a way to make those VPN'd devices able to access this ModemAccess IP too - if feasible - maybe by some sort of split-tunnel ruleset.
A few more days of testing, just to be sure.
But, for now, this works! -
Hmm, weird!
Well if it fails again check the states that are open from the internal client IP. You should see the pass state open on LAN and the NAT'd state on MODEMACCESS.
You could check that while it is working so you know what it should look like.Steve
