Can anyone reach their cable modem through OpnSense?

[cguilford]

What rule did you add and where?

[chemlud]

Firewall -> NAT -> Outbound (set to Hybrid)

Interface WAN

Source "Network of your MODEM, e.g. 192.168.100.0/24"

Translation/target INTERFACE address


____________

Save, apply, works here...

[cguilford]

Odd still no good here ahh well I'll have to connect up directly later with a laptop make sure that mine is in the 192.168.100.x range like it should be.

[jds]

Still does not work for me: see my NAT outbound rules.  I also ssh into the
OPNsense box and try to ping 192.168.100.1, but no return.

[chemlud]

SOURCE, not Destination is 192.168.100.0/24 (if that's your modems network)...

Interfaces -> Diagnostics -> Ping is the direct way ;-) And you have to allow ICMP in the firewall rules for LAN to make a ping work. And http/https to reach the web interface of your modem

[cguilford]

@chemlud can you provide a couple screenshots of what/how you have your rules setup, I've done the outbound Nat setup and I've created the LAN Rules to allow Network connectivity but something still appears to be missing.

[mitsos]

Unless the modem is configured in a "bridged" scenario (ie PPPoE on OPNSense), no other configuration is needed on OPNSense to access it.

If it's a double NAT scenario (which contrary to popular belief doesn't break *any* service, PAT does), and OPNSense has an IP in the modem's LAN subnet (ie gets it's IP directly from the modem/you have manually assigned an IP to OPNSense's WAN in the modem's LAN subnet), then it's routing 101: You are looking for the modem's IP, OPNsense answers "I see that IP, let me handle your packets for you" (=what a router does), you get connected, everything works.

Why it will not work:
1) you mess up with the outbound NAT rules.
2) you are blocking private/invalid on OPNSense's WAN
3) there isn't any rule that allows it (there should be, the default allow LAN to any, assuming you are connecting from OPNSense's LAN interface)
4) your modem is bridged, possibly using a specific port for the bridge, while leaving the rest as a "local tech support" access. ie port 1 is bridged, port 2+3 are not, port 4 is for a VOIP setup.

Works with cable, DSL, dialup, postal pidgeons, star trek communicators 

[chemlud]

Yepp, if I disable "Block private" on WAN, I can access the modem even without the NAT rule. However, with block private on WAN, the NAT rule takes over and allows the otherwise blocked private IP   of my modem...

fun!

[jds]

Clearly, I know far too little about networking.  I have "block private" disabled on WAN.
I have the WAN rules that chemlud suggests, and still cannot ping or reach the modem.
I have the allow all rule for LAN.  AFAIK the modem is not bridged or PPPoE.  I need a
more systematic way to study this stuff.  Or go back to something simpler.

[chemlud]

do a package capture (Interfaces -Diagnostics), first on LAN then on WAN while you try to access the modiem via http or https (depends...) and see, where your packages go to.

[jds]

LAN packet capture shows the only place my desktop goes is to the OPNsense box (on 443).
WAN packet capture did not show anything relevant that I can see: mostly packets between
my IP and the VPN IP, and the rest are ARP requests (for other IPs).

[chemlud]

So the traffic is apparently not leaving the LAN interface. Anything in the firewall logs?

Have a look here again, it works for me just fine:

Why it will not work:
1) you mess up with the outbound NAT rules.
2) you are blocking private/invalid on OPNSense's WAN
3) there isn't any rule that allows it (there should be, the default allow LAN to any, assuming you are connecting from OPNSense's LAN interface)
4) your modem is bridged, possibly using a specific port for the bridge, while leaving the rest as a "local tech support" access. ie port 1 is bridged, port 2+3 are not, port 4 is for a VOIP setup.

[jds]

The firewall shows that the destination to 12.168.100.1 is passed out.
But the source is my virtual IP for the VPN client.

Considering the list:
1) How would I know 
2) No blocking, checked again from Interfaces
3) There is a LAN to any rule
4) Not bridged or PPPoE, as far as I know.

[chemlud]

..post screenshot of NAT outbound... Again, here it works just fine ;-)

[jds]

Strangely, I had posted this before, but it somehow disappeared.
Here it is again.