New NIC - Now can't access cable modem GUI

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.