Can anyone reach their cable modem through OpnSense?

[chemlud]

I don't get it, why is 127.0.0.0 in there? Why are 192.168.1.0/24 and 10.0.10.0/24 there twice?

What is in the "Automatic rules" (more south on the same page...)

[jds]

I don't get it, why is 127.0.0.0 in there? Why are 192.168.1.0/24 and 10.0.10.0/24 there twice?

What is in the "Automatic rules" (more south on the same page...)

I don't remember anymore why 127.0.0.0 is there, and never really understood the logic of it.
The others are there because of the different interfaces ?

Is there a better way to do it?

[mitsos]

What the first rule of your NAT does: Take any packet from .100.0/24 (in which your cable modem is included) and translate it to .100.(OPNSense WAN IP). That's what's breaking it.

First rule on my list  ;)

Switch NAT to automatic, you don't need any manual rules. No you don't. Still don't need them  ;)

[jds]

Now I am more confused.  The first rule is what is supposed to be what allows me to reach the modem, and was added only recently in an attempt to reach it.  The other rules are necessary if I wish to go out through the VPN
client only (which is my goal), or so it was explained to me.  Or, there is a rule to work as a server.  I learned these
from the OPNsense documentation.  Are you saying that they are wrong?

[mitsos]

The first rule is a) wrong and b) not needed, so delete it. it is messing up everything in your modem's subnet. That's "a" reason for not reaching your modem. Planning ahead for "[citation needed]": You are taking the source subnet and translating it to the (same) destination or in simple words you are taking an orange and translating it to an orange.

VPN is another topic, for now we are talking about reaching your modem. Offtopic: you add a default route for your VPN, with exceptions for your local subnets (ie modem) as well as your remote endpoint (so it actually knows how to reach it when the tunnel is being established/off), not NAT. VPN endpoints are "routers", they understand routing in order for your packets to get from point A to point B. What I'm trying to say is you don't use NAT on the entry, you use it on the exit side, ie the server side. I doubt the OPNSense documentation said anything about adding NAT on your entry point.

Do me a favor, select automatic NAT (the first option), then post a screenshot of your modem's interface when it connects as a thanks  ;)

[jds]

Indeed if I replace all of my manual rules with automatic ones and reboot (necessary), I can access the
modem interface but not the intertubes.  If I also remove some of my firewall rules that block internet
access not through the VPN, then I can also access the intertubes, but  not through the VPN server.

It is not really off-topic to me (the OP) to say that I was looking for a way to access the cable modem without
destroying the other functionality, including VPN.  There is no official documentation on how to set up the
VPN client, just discussion in the forums (like here: https://forum.opnsense.org/index.php?topic=4979.msg19771#msg19771).

Now I need to find reliable documentation on how to set up the VPN client.

Thanks!

[mitsos]

Now that we fixed the modem access, on to fix the VPN:

Modify your "LAN to outside rule" so that the gateway used (there is a gateway option, you need to add the gateway's IP manually under  System > Gateways > Single) is the remote server's VPN address (the one you get *after* establishing the tunnel). That will force outgoing packets to go through that particular gateway and return packets (ie answers to *your* packets will have no other way but to flow through the VPN).

Make sure you don't get locked out. Check (and recheck) that there is a rule that allows OPNSense webgui access **BEFORE** your modified rule.

That modified gateway rule will direct everything over the tunnel. Assuming your provider (I see PIA mentioned there, so I'm going with private internet access) allows you to query DNS over the tunnel (it should) then the only thing left is to modify your DHCP server settings so that the DNS it gives is the PIA one and/or modify OPNSense's DNS (you really really should be using unbound in "full resolver" mode + have that go through the tunnel) and you have completed the circle. For unbound, create a rule to allow traffic from the firewall itself to the world + VPN gateway as before.

Feel free to adjust/add rules as you see fit for access. Also make sure that there is a rule that allows traffic from your LAN to your modem's subnet **before** the VPN rules.

Enjoy, you are welcome  :)

[jds]

Now that we fixed the modem access, on to fix the VPN:

Great, thanks.

Modify your "LAN to outside rule" so that the gateway used (there is a gateway option, you need to add the gateway's IP manually under  System > Gateways > Single) is the remote server's VPN address (the one you get *after* establishing the tunnel). That will force outgoing packets to go through that particular gateway and return packets (ie answers to *your* packets will have no other way but to flow through the VPN).

Are you sure that I need to add that gateway manually?  There is already one there labeled  PENVPNCLIENT_VPNV4.  Besides, how do I automate retrieval of that IP address?  Surely, it does not need to be added by hand each time?  At any rate, I added a gateway manually using the IP address of the VPN server, and made it the gateway for the LAN rule, but no dice.

By "LAN to outside rule" I assume that you mean the firewall rule under
the LAN interface that is currently "default allow LAN to any" rule.  At any rate, I changed that rule to have the VPN gateway mentioned above.

Make sure you don't get locked out. Check (and recheck) that there is a rule that allows OPNSense webgui access **BEFORE** your modified rule.

I assume that this is the anti-lockout rule in the same LAN interface, which gives access from anywhere to the LAN on ports 22,80 and 443.  It is indeed the first rule.

That modified gateway rule will direct everything over the tunnel. Assuming your provider (I see PIA mentioned there, so I'm going with private internet access) allows you to query DNS over the tunnel (it should) then the only thing left is to modify your DHCP server settings so that the DNS it gives is the PIA one and/or modify OPNSense's DNS (you really really should be using unbound in "full resolver" mode + have that go through the tunnel) and you have completed the circle. For unbound, create a rule to allow traffic from the firewall itself to the world + VPN gateway as before.

This is a little trickier, since I use a pihole for my DNS.  The DHCP server gives the IP of the pihole as the DNS server.  The pihole uses the OPNsense box on port 53 as its DNS server.  Then, I set the DNS server on the OPNsense box (under System->Settings->General) as the VPN DNS servers).  This is the only way that I could get it to work and not have DNS leaks anywhere.  I do have unbound enabled, but am not sure about "full resolver mode".

Feel free to adjust/add rules as you see fit for access. Also make sure that there is a rule that allows traffic from your LAN to your modem's subnet **before** the VPN rules.

Enjoy, you are welcome  :)

Not sure about where the last rule goes.  Well, I did the above.  The VPN logs shows that the "Initialization sequence is completed".  So the OpenVPN client is communicating fine with the
server.  From the OPNsense box, I can ping the outside world.  However, I then have no internet access from th LAN.  Only, if I change the gateway for "default allow LAN to any" rule back to default, do I get access, but not through the VPN.

[mitsos]

Are you sure that I need to add that gateway manually?  There is already one there labeled  PENVPNCLIENT_VPNV4.  Besides, how do I automate retrieval of that IP address?  Surely, it does not need to be added by hand each time?  At any rate, I added a gateway manually using the IP address of the VPN server, and made it the gateway for the LAN rule, but no dice.

1) Where did that gateway come from?
2) I'm willing to bet you used the public IP of the VPN server instead of the tunnel IP.

Not sure about where the last rule goes.  Well, I did the above.  The VPN logs shows that the "Initialization sequence is completed".  So the OpenVPN client is communicating fine with the
server.  From the OPNsense box, I can ping the outside world.  However, I then have no internet access from th LAN.  Only, if I change the gateway for "default allow LAN to any" rule back to default, do I get access, but not through the VPN.

The OPNSense box doesn't go through the VPN tunnel, that's why you can ping outside. Can you ping the VPN gateway (the remote server's tunnel IP, not the public IP) from the LAN?

WRT the DNS: your setup is a disaster, let's get the VPN fixed first then we'll worry about the DNS.

[jds]

1) Where did that gateway come from?
2) I'm willing to bet you used the public IP of the VPN server instead of the tunnel IP.
WRT the DNS: your setup is a disaster, let's get the VPN fixed first then we'll worry about the DNS.

I don't know, it was probably generated automatically when setting up the client, since I don't recall
ever modifying the gateway. It does report using the tunnel IP, though it is not put in manually in the settings.
It is set up as "dynamic".  I have modified it to be the manual tunnel IP: 10.x.x.x, and then made the
other changes as you suggest (automatic NAT outbound rules, LAN rule to use the new manually set gateway to the VPN tunnel).  There was no connectivity outside, so I reset the VPN connection.  Still no connectivity, though my OPNsense box is connected to the VPN server.  So, I rebooted the OPNsense box, checked that the tunnel IP is correct in the manually set single gateway (it had changed on reboot, of course), and then checked connectivity.  No. So then I tried to ping the tunnel IP, and yes I could.  I also discovered that from my LAN client I could ping 8.8.8.8 but not www.google.com, so it is now probably just a DNS problem, from my crazy set up.

I think that this is great progress, and once the DNS is working, it will all be working.

[mitsos]

Verify that ping is indeed going through the tunnel by capturing some traffic (interfaces > diagnostics > packet capture > your VPN interface) while pinging from your LAN.

If pinging with an IP works but not with the hostname, it's a DNS issue. Is the ahole, pardon pihole, on a different interface other than LAN by any chance?

I'm assuming you are using windows, so do an "nslookup www.google.com" from a command line when it's not working.

[jds]

No, when I ping from my LAN client, the ping is just being returned from the OPNsense box for some reason.

I have also simplified my DNS service by making it the PIA DNS servers in the DHCP server, and eliminated everything that refers to the pihole.  This allows me to ping either 8.8.8.8 or www.google.com from the OPNsense box, but have no connectivity to outside for the LAN clients.  I have been experimenting with lots of other things,
but no progress, so won't even detail those.

[jds]

BTW, I did use nslookup (on linux), but nothing returns.

Now I am not so sure that there is any progress here. My original setup (that I keep returning to),
at least gives me internet connectivity on all clients through the VPN, no DNS leaks, and allows me
to use the pihole (which I could maybe accomplish with BIND).  The downsides are that it is complicated
on the firewall and DNS settings, and that I cannot reach the cable modem. 

So far, the only other option I have is to drop VPN, and then sometimes reach the outside world without
VPN.  I write "sometimes" because that is actually not even reproducible, as I learned today.  I follow what
seem to be identical steps, but no longer reach the outside world without VPN for the LAN client.  Who knows, maybe I am forgetting to reboot the OPNsense box at the right moment, or not restarting my LAN client connection to get some new DNS server instruction at the right moment, or not dancing with a chicken today, or
who knows what.  In reality, I probably need to know a great deal more about networking in order to use
this tool.  Maybe it would be better for me to go to something simpler, like openwrt.  Yeah, I am sure that you can
tell that I am getting frustrated working on this problem without progress for almost a week. 

I am also sure that you see progress, but it is hard to tell from this end.  Despite my frustration, I do greatly
appreciate your efforts.

[mitsos]

You are changing too many things and I can't keep track. Doing this without being in front of the screen to properly troubleshoot it is already confusing.

Recap:
1) Set up your VPN tunnel (check that auto NAT is enabled)
2) Change the "LAN to any" allow rule to gateway > VPN.
3) Then actually post the output for:
3a) ping from your LAN to your OPNSense
3b) ping from your LAN to the VPN gateway (the PIA server's VPN IP)
3c) ping from your LAN to 8.8.8.8
3d) ping from your LAN to www.google.com
3e) On OPNSense Interfaces > Diagnostics > DNS lookup for www.google.com
3f) You mentioned linux, so I'm assuming that you are using linux instead. Do a "dig www.google.com" from your LAN.
3g) Post your OPNSense routes when the tunnel is established (System >  Routes> Configuration), redact if necessary.

[jds]

3a) Ping from LAN client to OPNsense box:
PING 192.168.1.50 (192.168.1.50) 56(84) bytes of data.
64 bytes from 192.168.1.50: icmp_seq=1 ttl=64 time=6.30 ms
64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=3.73 ms
64 bytes from 192.168.1.50: icmp_seq=3 ttl=64 time=2.77 ms

3b) Ping from LAN client to the VPN gateway:
PING 199.116.115.133 (199.116.115.133) 56(84) bytes of data.
64 bytes from 192.168.1.50: icmp_seq=1 ttl=64 time=3.47 ms
64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=4.39 ms
64 bytes from 192.168.1.50: icmp_seq=3 ttl=64 time=2.53 ms

or if I use the tunnel IP
PING 10.83.10.6 (10.83.10.6) 56(84) bytes of data.
64 bytes from 10.83.10.6: icmp_seq=1 ttl=64 time=3.28 ms
64 bytes from 10.83.10.6: icmp_seq=2 ttl=64 time=8.03 ms
64 bytes from 10.83.10.6: icmp_seq=3 ttl=64 time=7.03 ms
64 bytes from 10.83.10.6: icmp_seq=4 ttl=64 time=6.86 ms

3c) Ping 8.8.8.8 from LAN:
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 192.168.1.50: icmp_seq=1 ttl=64 time=4.01 ms
64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=3.12 ms
64 bytes from 192.168.1.50: icmp_seq=3 ttl=64 time=3.70 ms

3d) ping from LAN to www.google.com
ping: www.google.com: Name or service not known

3e) DNS lookup of www.google.com using the Interfaces Diagnostic returns nothing.

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56248
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; Query time: 23 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Mar 25 16:40:25 CDT 2019
;; MSG SIZE  rcvd: 43

3f) System:Routes:Configuration
No results found!