Routing to 192.168.100.1 (cable modem) across pfSense WAN interface

viragomann

@jhg said in Routing to 10.0.0.1 (cable modem) across pfSense WAN interface:

I've tried disabling "Block Private Networks"

This only affects incoming connections. But I think, you aim to access the modem web GUI from LAN through pfSense. So this would be an outbound connection.

Traceroute shows the packets reach the pfSense box but no further.

I'd suspect, that the packets even go further, but no response is coming back.

Is there a way to do this?

See the docs chapter Accessing a CPE/Modem from Inside the Firewall.

jhg

@viragomann said in Routing to 10.0.0.1 (cable modem) across pfSense WAN interface:

@jhg said in Routing to 10.0.0.1 (cable modem) across pfSense WAN interface:

I've tried disabling "Block Private Networks"

This only affects incoming connections. But I think, you aim to access the modem web GUI from LAN through pfSense. So this would be an outbound connection.

Traceroute shows the packets reach the pfSense box but no further.

I'd suspect, that the packets even go further, but no response is coming back.

Is there a way to do this?

See the docs chapter Accessing a CPE/Modem from Inside the Firewall.

Thanks, that looks promising. I'll try it this evening.

stephenw10

If it's not PPPoE then add a VIP to the WAN in the 10.0.0.X subnet and translate traffic to that instead.

jhg

I was incorrect on the IP address 10.0.0.1, it's actually 192.168.100.1. I updated my configuration and messed around with it for a couple of hours with no luck, until I tried setting the VIP's netmask to the same value as the netmask provided by the ISP's DHCP. In other words, when the VIP was /32 or /24 it wouldn't work, but as soon as I changed it to /22 to match my ISP-provided address, it worked. I guess that requirement could be a bit clearer.

re1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        description: WAN
        options=201b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,WOL_MAGIC>
        ether [redacted]
        inet [redacted] netmask 0xfffffc00 broadcast 255.255.255.255
        inet 192.168.100.2 netmask 0xfffffc00 broadcast 192.168.103.255

Thanks for the pointer to the document. Would it be possible to update it with the note about what to do if your WAN is not PPPoE, and also add a note about the VIP's netmask?

Thanks.

chpalmer

@jhg pfsense does not block outbound connections to any address by default. 192.168.100.1 is a very popular address for cable modems and works in every instance I have ever been employed to work on.

In some cases though the ISP can block your access or even make it so the modem cannot respond upstream out of the network (192.168.100.0/24) so that the only way you can see it is being on that network. Steve's recommendation above would get by that..

But to drill that in.. pfsense by default will allow you to see your cable modem's GUI from devices behind pfsense.

jhg

@chpalmer said in Routing to 10.0.0.1 (cable modem) across pfSense WAN interface:

@jhg pfsense does not block outbound connections to any address by default. 192.168.100.1 is a very popular address for cable modems and works in every instance I have ever been employed to work on.

In some cases though the ISP can block your access or even make it so the modem cannot respond upstream out of the network (192.168.100.0/24) so that the only way you can see it is being on that network. Steve's recommendation above would get by that..

But to drill that in.. pfsense by default will allow you to see your cable modem's GUI from devices behind pfsense.

That's always worked for Xfinity modems because they'll accept incoming traffic on their LAN port from any address. I stopped paying Comcast's rental fee and bought a Hitron CODA56 (which works great). However, it requires the traffic to its web interface to have a source IP in the 192.168.100.0/24 netblock, and refuses to respond to anything else. This is documented in various places including Hitron's FAQs.

I did get it working after reading the "fine print" in the VIP setup page.

stephenw10

Yes a lot of cable modems will respond on the management IP without needing a VIP like that because pfSense will NAT to it's WAN address and the modem knows where that is. Most PPPoE modems cannot though as the PPPoE connection bypasses it entirely.

I would have expected /24 to work there since that's in the subnet.

jhg

@stephenw10 said in Routing to 10.0.0.1 (cable modem) across pfSense WAN interface:

I would have expected /24 to work there since that's in the subnet.

That's what I thought until I went back and read this:

stephenw10

The only thing that should matter there is that the device you're trying to connect to is inside the subnet defined by the mask so it's able to ARP for it. If it was a much smaller mask the target device might not be able to reply but that isn't the case here.

kurtz_p

@jhg Thank you, I verified my WAN interface subnet matched it with the Virtual IP address and it I could get to the modem. Without this little bit of information it would not work.

jhg

@stephenw10 said in Routing to 10.0.0.1 (cable modem) across pfSense WAN interface:

The only thing that should matter there is that the device you're trying to connect to is inside the subnet defined by the mask so it's able to ARP for it. If it was a much smaller mask the target device might not be able to reply but that isn't the case here.

I agree it shouldn't matter, but for some reason it does.

stephenw10

Hmm, weird. I can't see how the modem would know or care what the client mask is.

johnpoz

Not sure what you think is happening here.. But I access my cable modem on 192.168.100.1 and mask of my public IP makes no difference.. How would it..

Mask doesn't matter anyway when 2 devices that talk to each other.. You can for sure can have a mismatch and still talk, as long as both devices think the other device is on their local network..

You could for sure have say a 192.168.100.1 and .2 talk to each other when one had a /24 mask and the other had a /25 or /16 or whatever.. Where you run into trouble is when one side doesn't think the other IP is on its own network.

The mask on my vip is /24 and the mask I get on my public IP is a /20

I ran into something weird a while back where disable reply to on my floating rule above my deny other rfc1918 being a good netizen and blocking noise from entering the internet.

But It makes no sense that mask on your wan interface, or mask on your vip would matter in the least as long as the modem thinks your vip is on the same network as it. And when pfsense is wanting to talk to the 100.1 that it thinks that is on the same network as its vip.

edit.. btw I just removed the vip and disabled my outbound rules for both the vip and blocking the rfc, no outbound nat rule to my vip, etc.. And I can still talk to my cable modem..

I just had those in there because I was helping someone else out that was having the weirdness about the replyto and wanted to be able to replicate his setup..

kurtz_p

@johnpoz I don't think it matter now either, because I changed the mask to 192.168.100.0/24 and Virtual IP to the same and it works. I think the web interface on the Hiltron CODA56 running SW Version 7.3.5.0.1b5 seems like its goes unresponsive. I rebooted the modem and the web interface was back. Seems like they had issue with older code, but pfsense is working as it should.