I'm trying to setup a simple static route to my second router. It's a Netgear Nighthawk R7000 router. Eventually I'm going to set this router up in AP mode, but I have a lot of IP addresses reserved in the router and I'm not ready to migrate those to OPNsense just yet.
LAN IP Range: 10.0.0.0/24
Second Router IP: 10.0.0.10
I'm attempting to route 192.168.1.0/24 traffic to the second router which is at 10.0.0.10. The second router settings have been modified so that I can ping from the WAN and NAT filtering was set to Open.
My OPNsense setup is essentially the default OPNsense install. I haven't added any additional firewall rules or changed any settings. I just assigned the interfaces and their ip addresses and then attempted to setup this static route.
Attached are the settings I've configured for the static route and the associated gateway. I'm trying to determine if the issue is within OPNsense or the Netgear router. When I run a traceroute from OPNsense to any address on the second router 192.168.1.0/24 network, I'm not seeing any hop attempt through 10.0.0.10, which leads me to believe that the issue is with OPNsense. Please let me know if I'm mistaken in that assumption.
traceroute output:
root@OPNsense:~ # traceroute 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 64 hops max, 40 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
^C
root@OPNsense:~ # traceroute -m 3 192.168.1.7
traceroute to 192.168.1.7 (192.168.1.7), 3 hops max, 40 byte packets
1 * * *
2 * * *
3 * * *
root@OPNsense:~ #
netstat output (WAN removed to protect IP):
root@OPNsense:~ # netstat -rWn
Routing tables
Internet:
Destination Gateway Flags Nhop# Mtu Netif Expire
10.0.0.0/24 link#2 U 3 1500 igb1
10.0.0.1 link#2 UHS 9 16384 lo0
127.0.0.1 link#7 UH 8 16384 lo0
192.168.1.0/24 10.0.0.10 UGS 1 1500 igb1
Ping output:
root@OPNsense:~ # ping 10.0.0.10
PING 10.0.0.10 (10.0.0.10): 56 data bytes
64 bytes from 10.0.0.10: icmp_seq=0 ttl=64 time=0.786 ms
64 bytes from 10.0.0.10: icmp_seq=1 ttl=64 time=0.427 ms
64 bytes from 10.0.0.10: icmp_seq=2 ttl=64 time=0.714 ms
64 bytes from 10.0.0.10: icmp_seq=3 ttl=64 time=0.495 ms
64 bytes from 10.0.0.10: icmp_seq=4 ttl=64 time=0.461 ms
64 bytes from 10.0.0.10: icmp_seq=5 ttl=64 time=1.451 ms
64 bytes from 10.0.0.10: icmp_seq=6 ttl=64 time=0.679 ms
64 bytes from 10.0.0.10: icmp_seq=7 ttl=64 time=0.577 ms
^C
--- 10.0.0.10 ping statistics ---
8 packets transmitted, 8 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.427/0.699/1.451/0.309 ms
root@OPNsense:~ # ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
^C
--- 192.168.1.1 ping statistics ---
13 packets transmitted, 0 packets received, 100.0% packet loss
root@OPNsense:~ # ping 192.168.1.7
PING 192.168.1.7 (192.168.1.7): 56 data bytes
^C
--- 192.168.1.7 ping statistics ---
7 packets transmitted, 0 packets received, 100.0% packet loss
Static routes are new to me and obviously I'm missing something. Any help would be very much appreciated.
you have no issues sending the pings to 192.168.1.0/24... I think that subnet does not know how to get back. :D
I really appreciate the reply. I definitely don't have any routes configured in the second router, but I was under the impression that NAT would still occur here, which would allow the devices on the second router to respond when pinged. Is that not the case? Any ideas on how I can troubleshoot this?
Quote from: lilsense on July 30, 2023, 02:55:24 AM
you have no issues sending the pings to 192.168.1.0/24... I think that subnet does not know how to get back. :D
To rule this out, I opened wireshark on one of my machines on the 192.168.1.0/24 network and filtered by ICMP to see if the ping requests were being received, but couldn't find a path back like you postulated.
The pings are not making it to this device at all. This is in line with the traceroute showing no hops at all. I'm fairly confident that OPNsense isn't sending requests to 192.168.1.0/24 through the 10.0.0.10 gateway.
I don't know if that means my route isn't configured correctly or if that means additional firewall rules are required to use the route? Any guidance here would be very much appreciated.
Is there any tracing or logging that I could use to observe that? The logs that I've looked at so far don't seem like they're logging blocked traffic - Maybe logging is disabled - I'm not sure.
Well.... after some digging into the firewall it seems that these ping requests are not being blocked by the firewall (see attachment).
So if they're not being blocked by the firewall and they're not being received by any of the devices on the 192.168.1.0/24 network, then I guess they're probably being dropped by the second router.
Maybe traceroute doesn't show the hops because the device at the gateway never responds?
Is there a way I can watch the traffic go from OPNsense to the gateway, besides traceroute, just so I know for sure that it made it to the gateway?
Quote from: groach45 on July 29, 2023, 09:22:48 PM
The second router settings have been modified so that I can ping from the WAN and NAT filtering was set to Open.
What exactly does the bold part mean? You have to completely disable NAT on the second router if you want to access its LAN from the WAN.
Quote from: groach45 on July 30, 2023, 05:29:39 AM
Is there a way I can watch the traffic go from OPNsense to the gateway
Interfaces: Diagnostics: Packet Capture
Thanks for the reply.
From what I can tell setting NAT filtering to Open allows some point to point traffic, but it's unclear exactly what that means. I don't see any option to disable NAT completely. Here is the manual which vaguely describes the NAT setting:
https://www.manua.ls/netgear/nighthawk-r7000/manual?p=118
Thanks for the tip with the packet capture! I can confirm now that the packets are indeed getting routed to the Netgear router through the gateway, so the issue is with the Netgear router (see screenshot).
I guess I should probably just bite the bullet and go ahead and move all my reserved IPs into OPNsense and set the wireless router up in AP mode.
Where is the internet connected to?
They probably mean full-cone NAT, restricted-cone NAT or something like this, but this won't help you.
I agree, if there is no advanced option to put this thing in actual routing mode, then you should use it as an AP only, or install third-party firmware, or ditch it.