New NIC - Now can't access cable modem GUI
-
Yes. Pingable from both pfSense diagnostics & LAN side clients. About 2ms response time from both.
Outbound NAT is set to automatic. (firewall/routing rules are the defaults)
Cable modem is a Sagemcom F@ST 3896 in bridged mode (if it matters).
-
Some cable modems have to be rebooted when the NIC or computer has been changed.
-
Some cable modems have to be rebooted when the NIC or computer has been changed.
i'd venture to say 'all' but would settle for 'most.' L2/ARP cache thing.
another thing i've personally wrestled with before: doesn't sound like you are, but make sure you're not using any 'custom' DNS entry for the modem and attempting access only via its IP address. modern browser certificate checks, not-worth-tracking-down-in-browser-settings and whatnot kinda thing.
multiple non-cached browsers to corroborate one another.
-
@JKnott Yes, had to reboot modem and then router to regain internet access, but no joy with the modem login.
-
You need a virtual IP an WAN like this:
-
Yup probably that^.
Hard to explain how that worked with the other NIC though...
-
@alhaunts pull the power on the modem (technically a 'gateway device' since it functions as both modem and router) for at least 30 seconds. failing that you could...
1.) call ISP to ensure they don't need to whitelist your access. new NIC's MAC address would be the operative piece of information.
2.) buy your own modem.there's at least a few technical reasons i can think of, based on your description of everything, why you were able to access this GUI before—and now you can't after simply swapping a NIC. but it's not worth delving into if you're simply failing to clear caches through a simple power-cycle and/or need the ISP's assistance.
and it can't be overstated: buy your own modem if the ISP permits it.
-
@NOCling said in New NIC - Now can't access cable modem GUI:
You need a virtual IP an WAN like this:
@stephenw10 said in New NIC - Now can't access cable modem GUI:
Yup probably that^.
Hard to explain how that worked with the other NIC though...
no. not unless OP is filtering outbound traffic on the LAN side, which i think we can safely assume is not the case.
@alhaunts just thought of something else while writing this reply—are you using the 192.168.100.1/24 (or smaller) subnet anywhere else on your network?
-
Many modem devices will require a VIP and NAT to it so they have a route back to reply. But that would not change with the NIC.
-
@stephenw10 if the gateway device is echoing pings... there's already a route out and back.
-
Can you telnet to 192.168.100.1 on port 80?
-
This post is deleted! -
@cyberconsultants True!
-
So ran into something like this a while back.. Where you had to do something with reply-to or something.. Let me see if can dig up that thread..
I currently can access mine on 192.168.100.1 but I know I had to change my rules a bit and could duplicate what the poster was seeing.. give me bit, brb.
edit: ok this is the thread I was thinking about.
https://forum.netgate.com/topic/181715/solved-problems-with-understanding-advanced-egress-filtering
We kind of went down the wrong rabbit hole for a bit.. But this is what I currently have set
Notice reply-to is set to disabled. If I allow the reply-to it doesn't work..
My vip is set to 192.168.100.2 and my modem is at 192.168.100.1
Have to reread over the thread, but I think if you turned off the whole blocking outbound to rfc1918 it worked without having to disable reply-to.
I kept meaning to dive into the reply-to and outbound blocking and order deeper, but then got side tracked.
-
That's outbound on WAN?
That might be bypassed by adding a VIP so it appears as a local subnet. Hmm.
Still wouldn't change by using a different NIC though
-
@stephenw10 said in New NIC - Now can't access cable modem GUI:
That might be bypassed by adding a VIP so it appears as a local subnet. Hmm.
it's actually the opposite. not 'appearing as a local subnet' is exactly what causes a L3 packet to be routed outbound regardelss of whether the destination is an RFC1918 address (in this case 192.168.100.1) or not.
OP either has uncleared caches, needs to be whitelisted by ISP, or is using a subnet that includes the address 192.168.100.1 somewhere on the LAN side. those are really the only possibilites based on the information we have.
@johnpoz said in New NIC - Now can't access cable modem GUI:
We kind of went down the wrong rabbit hole for a bit.. But this is what I currently have set
i have no issue accesing my modem that sits outside my edge firewall @ 192.168.100.1 with none of the kludge that you suggest.
-
@cyberconsultants are you blocking outbound rfc1918? I don't have a problem either if I don't block outbound rfc1918.
-
@johnpoz originating from WAN? yes. originating from LAN? no. that's what NAT is for.
-
@cyberconsultants Look at the rules, I block outbound traffic to rfc1918... Being a nice netizen - there is zero reason to allow rfc1918 to go outbound.
Its not stopping my local rfc1918 from being natted, its blocking traffic destination rfc1918.
No its not a necessary sort of rule.. But many people do it.. If I say typo trying to go say 192.168.11.42 vs say my local 192.168.1.42 it would get routed out my wan.. Which isn't going to go anywhere but why even let it out.
I originally put it in because I had a work laptop that when wasn't on its vpn connection would spew out trying to talk to "work" stuff on other rfc1918 IPs where were not any of my local networks and would route it out the wan..
I just brought it up because have seen weirdness if you were doing that were you couldn't talk to your modem - unless you set the rule above it that allows to the 192.168.100.1 (modem) to not do the reply-to. The OP might have had such a rule..
My previous modem would answer without having to nat to 192.168.100.x vip.. But this modem does not.
-
@johnpoz said in New NIC - Now can't access cable modem GUI:
Being a nice netizen - there is zero reason to allow rfc1918 to go outbound.
i can think of at least one apropos to this thread: accessing my own modem outside the firewall!
the rest of what you discuss, again, is what NAT is for. when i access my modem from the inside, edge router sees an RFC 1918 source, NATs that to its WAN address, and sends the outbound traffic to that single RFC 1918 sitting right outside. modem (also a RFC 1918 source from its own perspective) directs its reply traffic back to the WAN address, edge router does the 'un-NAT', and me and the modem carry on our conversation. the modem technically never sees an RFC 1918 host.
client-to-site tunnel traffic is a different consideration altogether if the outbound traffic is, in fact, tunneled.
EDIT: strike that last part, i misread. you said when your laptop's VPN was not connected. preventing outbound RFC 1918 from originating on LAN makes sense in that case i suppose.