New NIC - Now can't access cable modem GUI

stephenw10

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.

tinfoilmatt

@stephenw10 if the gateway device is echoing pings... there's already a route out and back.

provels

Can you telnet to 192.168.100.1 on port 80?

stephenw10

This post is deleted!

stephenw10

@cyberconsultants True!

johnpoz

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.

stephenw10

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

tinfoilmatt

@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.

johnpoz

@cyberconsultants are you blocking outbound rfc1918? I don't have a problem either if I don't block outbound rfc1918.

tinfoilmatt

@johnpoz originating from WAN? yes. originating from LAN? no. that's what NAT is for.

johnpoz

@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.

tinfoilmatt

@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.

johnpoz

@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

tinfoilmatt

@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. ;)

tinfoilmatt

@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).

johnpoz

@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

Normally 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.

stephenw10

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.

tinfoilmatt

@johnpoz just to be clear, you're talking about this checkbox on your LAN interface/s config?

two thoughts:

1.) those checkboxes simply create highest-priority rules, like so for my WAN interface where i do have that box checked:

block drop in quick on ix0 inet from 10.0.0.0/8 to any label "Block private networks from WAN block 10/8" ridentifier 12001
block drop in quick on ix0 inet from 127.0.0.0/8 to any label "Block private networks from WAN block 127/8" ridentifier 12002
block drop in quick on ix0 inet from 172.16.0.0/12 to any label "Block private networks from WAN block 172.16/12" ridentifier 12003
block drop in quick on ix0 inet from 192.168.0.0/16 to any label "Block private networks from WAN block 192.168/16" ridentifier 12004
block drop in quick on ix0 inet6 from fc00::/7 to any label "Block ULA networks from WAN block fc00::/7" ridentifier 12005

2.) as far as outbound RFC 1918 originating on LAN traffic is concerned—meaning egress LAN traffic where the source is any RFC 1918 address that's not within a locally connected subnet—that's taken care of by a manual 'default deny' rule. this sits at the bottom (not the top) of my LAN ruleset:

@stephenw10 said in New NIC - Now can't access cable modem GUI:

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.

i don't believe that's true. a modem directly-connected to the WAN interface doesn't need a route at all because, well, the interface it's replying to is directly-connected (or if a switch is in-between, is still within the same broadcast domain.)

johnpoz

@cyberconsultants said in New NIC - Now can't access cable modem GUI:

just to be clear, you're talking about this checkbox on your LAN interface/s config?

Why would I block rfc918 on my lan side.. It needs to talk to pfsense which is rfc1918, it needs to talk to my other rfc1918 networks.. When you block rfc1918 with that check box it is like the first rule.. No way to ever override it..

The blocked to rfc1918 is "outbound" on the wan side.. Floating tab allows you create the oubound blocks. Interface rules only allow blocks inbound into the interface.

See the little black arrow in a circle on the floating tab rules - that tells you which direction the rule is applied, inbound to the interface or outbound from the interface.

Now you could create rules on your lan side that block traffic to unknown rfc1918, after you allow what you want to your other rfc1918 rules above it. And that might be better way to keep unknown rfc1918 from going out your wan.. But it would require the rules to be placed on every lan side interface. The outbound rules makes it just 1 rule on 1 interface.

alhaunts

@cyberconsultants No, not using 192.168.100.1/24 anywhere else.