New NIC - Now can't access cable modem GUI
-
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:
login-to-view@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.
-
@cyberconsultants said in New NIC - Now can't access cable modem GUI:
i can think of at least one apropos to this thread: accessing my own modem outside the firewall!
exactly which is why there is a rule to allow that..
edit: I just double checked, if I disable the blocking outbound nat rule.. I can access my modem without doing any vip.. Some modems do it, some do not..
So currently I disable the outbound nat and the nat to the vip and I can access it just fine. But if I turn on that block outbound rfc1918 rule, even though there is a rule infront of it that should allow to 192.168.100.1.. I have to enable the vip for it to work.. and set disable the reply-to.
I agree with you normally you should just be able to access it..
But depending on the rules the OP has they could run into some weirdness.. I really should take a bit to look at the rules directly to why this doesn't work if you block outbound to rfc1918, even when you have rule before it that should allow to 192.168.100.1 It is odd..
So if I want to leave my blockoutbound rfc1918, I have to disable reply-to in the allow to 192.168.100.1 and I have to use a vip to have my traffic be coming from 192.168.100.x
-
@johnpoz we agree that if your use case requires outbound RFC 1918 originating on LAN to be blocked, then you're going to need a lil' kludge. ;)
-
@johnpoz said in New NIC - Now can't access cable modem GUI:
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.
that actually would go somewhere. it would end up at the destination as-typed with your WAN address as the source (assuming NAT).
-
@cyberconsultants said in New NIC - Now can't access cable modem GUI:
that actually would go somewhere. it would end up at the destination as-typed with your WAN address as the source (assuming NAT).
exactly -- but its not going to really go anywhere unless my ISP has something on that 192.168.11.42 address. It sure not going to route anywhere else over the public internet.
I did a bit of edit on the previous post.. I think we are in agreement.. Normally out of the box, unless the modem is odd you should just be able to access your 192.168.100.1 (modem) address directly from your public Wan IP..
Here if I turn off the outbound blocks to rfc1918, and disable the vip the page works just fine.
But "depending" on your rules and modem you might have to do a bit of kludge..
With the block rules in place this noise can go out to the public internet
Sniff on my wan
login-to-viewNormally who cares, just a some noise - but there really is little reason to let such noise out, the internet is noisy enough place.. I noticed it on my work laptop when the vpn would time out and disconnect and the laptop would start spewing a bunch of noise like that trying to talk to its work stuff, which sure works when the vpn is active on it. But not so much when not ;) Even though pfsense would still try to route it.
-
A lot of modems in bridge mode, including mine, have no route to the public IP on the pfSense WAN. Without a VIP in the management subnet on the WAN to NAT via they have no way to respond.
Clearly this one doesn't require that though because, as said, ping works. When you have ping working but TCP failing it's almost always some asymmetric routing issue.
However none of that would be changed by swapping out the WAN NIC in pfSense.