New NIC - Now can't access cable modem GUI

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.

stephenw10

I would probably try adding a VIP in that subnet on the WAN and an outbound NAT rule via it since doing so can't hurt.

Otherwise I would run a ping to the modem IP and check the state table in Diag > States. Is it actually leaving via the WAN as expected?

alhaunts

@provels

No response to a telnet attempt either. I'm starting to think my modem may be what's effed-up here. Gonna try swapping it with the ISP and see what happens.

tinfoilmatt

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

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

which is why i don't use it on the LAN side, like i've been saying all along. i do keep that box checked on my WAN interface however—again, like i've been sayin all along. you use a floating rule apparently, gotcha.

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

Interface rules only allow blocks inbound into the interface.

that's not true. both ingress and egress traffic is assessed against the interface's ruleset.

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

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.

exactly. not 'might,' it is a superior firewalling method. but enough talking at each other and derailing OP's thread.

@alhaunts do update us with the resolution, will ya? lol

stephenw10

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

both ingress and egress traffic is assessed against the interface's ruleset.

Whilst that's technically true for the underlying pf rulset; in pfSense the default rules allow all traffic outbound on any interface regardless of the user applied rules on that interface. Except if those rules are outbound on the floating rules tab.

tinfoilmatt

@stephenw10 the statement is patently true as far as the very concept of firewalling is concerned. everything else you mention is well-addressed in the documentation i've linked on egress filtering.

if you use the convenient 'Block private networks and loopback addresses' checkbox on the WAN side and then also configure an egress floating rule, then guess what you've got on at least the WAN side? kludge, albeit mild.

stephenw10

Assuming you mean a block rule outbound those would do different things. Applying both is legitimate if, like @johnpoz, you want to prevent opening connections to private IPs on the WAN.

tinfoilmatt

@stephenw10 i don't follow this reply and would genuinely like to know what you mean.

simple hypothetical: two interfaces only, WAN and LAN.

WAN has the 'Block private networks and loopback addresses' checked.

LAN contains a manually-configured 'default deny' rule (i.e. drop any-any -> any any) at the bottom of its ruleset. a rule passing only '192.168.1.0/24 any' as the source, destination 'any any' sits above it.

are you suggesting a floating rule would still be needed in this scenario?

stephenw10

It's not needed since traffic to private IPs leaving WAN is not normally an issue. But in that scenario if a client on LAN tries to ping, for example, 10.100.0.1 that traffic will be passed and routed out of the WAN to the WAN gateway.

tinfoilmatt

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

in that scenario if a client on LAN tries to ping, for example, 10.100.0.1 that traffic will be passed and routed out of the WAN to the WAN gateway.

if both the 'default deny' rule and the pass rule are configured with protocol 'any' (which i failed to consider in the details of my hypothetical)—that's true!

if, however, the 'default deny' rule is configured with protocol 'any' and the pass rule is configured only for protocol TCP/UDP, then that's not true.

regardless, i maintain my position that all of this is more succintly maintained on a per-interface basis.

stephenw10

I don't have a block outbound rule like that because I don't think it's necessary. But in more complex environments if you really don't want any traffic to private IPs leaving WAN it's the easiest way to ensure that. Maintaining all the rules on each interface if you're adding/removing subnets becomes significant work and open to error.

tinfoilmatt

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

But in more complex environments if you really don't want any traffic to private IPs leaving WAN it's the easiest way to ensure that.

i suppose i could agree with that (sledgehammer-nail approach notwithstanding).

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

Maintaining all the rules on each interface if you're adding/removing subnets becomes significant work and open to error.

i also agree with that. friendly reminder to audit your rules regularly, folks!

i should also mention my view is likely skewed by using pfSense purely for edge routing and firewalling—only a /30 'transit' subnet configured on the LAN side connected directly to core router.

appreciate the spirited discussion on this (and with you too, @johnpoz).

alhaunts

On a hunch, I swapped the modem for one of the same model from my ISP. Problem is solved & I have GUI access once again. Chalking it up to coincidence with the modem failing at the same time NIC was replaced.

Thanks to everyone for your assistance.