New NIC - Now can't access cable modem GUI
-
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.
-
@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
-
@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.
-
@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.
-
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.
-
@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?
-
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.
-
@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.
-
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.
-
@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).
-
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.
