Static IP device - static routes bypass routing table

otnert · August 21, 2018, 12:18pm

Here is the output, it took a little longer as the format was incorrect, I've added the network config at the end.

Do these sections need to be filled out with IP's?

	option target '0.0.0.0'
	option netmask '0.0.0.0'

I think it's not picking up the exvpn table

root@LEDE:~# ip -4 rule
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

root@LEDE:~# ip -4 route show table all
0.0.0.0/1 via 10.7.10.5 dev tun0
default via 192.168.10.1 dev eth0  proto static  src 192.168.10.4
8.8.4.4 via 192.168.2.1 dev br-lan  proto static  metric 2
8.8.8.8 via 192.168.2.1 dev br-lan  proto static  metric 2
10.7.10.1 via 10.7.10.5 dev tun0
10.7.10.5 dev tun0  proto kernel  scope link  src 10.7.10.6
128.0.0.0/1 via 10.7.10.5 dev tun0
168.1.75.54 via 192.168.10.1 dev eth0
192.168.2.0/24 dev br-lan  proto kernel  scope link  src 192.168.2.1
192.168.3.0/24 dev br-guest  proto kernel  scope link  src 192.168.3.1
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.4
192.168.10.1 dev eth0  proto static  scope link  src 192.168.10.4
local 10.7.10.6 dev tun0  table local  proto kernel  scope host  src 10.7.10.6
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1
broadcast 192.168.2.0 dev br-lan  table local  proto kernel  scope link  src 192.168.2.1
local 192.168.2.1 dev br-lan  table local  proto kernel  scope host  src 192.168.2.1
broadcast 192.168.2.255 dev br-lan  table local  proto kernel  scope link  src 192.168.2.1
broadcast 192.168.3.0 dev br-guest  table local  proto kernel  scope link  src 192.168.3.1
local 192.168.3.1 dev br-guest  table local  proto kernel  scope host  src 192.168.3.1
broadcast 192.168.3.255 dev br-guest  table local  proto kernel  scope link  src 192.168.3.1
broadcast 192.168.10.0 dev eth0  table local  proto kernel  scope link  src 192.168.10.4
local 192.168.10.4 dev eth0  table local  proto kernel  scope host  src 192.168.10.4
broadcast 192.168.10.255 dev eth0  table local  proto kernel  scope link  src 192.168.10.4

/etc/config/network....

config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fda18:9c28:b6ab2::/48'

config interface 'lan'
	option type 'bridge'
	option proto 'static'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option _orig_ifname 'eth1 wlan0 wlan1'
	option _orig_bridge 'true'
	option ifname 'eth1'
	option ipaddr '192.168.2.1'

config interface 'wan'
	option ifname 'eth0'
	option proto 'dhcp'
	option peerdns '0'
	option dns '209.222.18.222 209.222.18.218'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '1 2 3 4 6'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '5 0'

config interface 'PIA_VPN'
	option proto 'none'
	option ifname 'tun0'

config interface 'guest'
	option _orig_ifname 'wlan0-1'
	option _orig_bridge 'false'
	option proto 'static'
	option ipaddr '192.168.3.1'
	option netmask '255.255.255.0'
	option type 'bridge'

config route
	option interface 'lan'
	option target '8.8.8.8'
	option netmask '255.255.255.255'
	option gateway '192.168.2.1'
	option metric '2'

config route
	option interface 'lan'
	option target '8.8.4.4'
	option netmask '255.255.255.255'
	option gateway '192.168.2.1'
	option metric '2'

config route
	option interface 'wan'
	option target '0.0.0.0'
	option netmask '0.0.0.0'
	option gateway '192.168.10.1'
	option table 'exvpn'

config rule
	option in 'lan'
	option src '192.168.2.250'
	option lookup 'exvpn'

config rule
	option in 'lan'
	option src '192.168.2.251'
	option lookup 'exvpn'

config rule
	option in 'lan'
	option src '192.168.2.252'
	option lookup 'exvpn'

config rule
	option in 'lan'
	option src '192.168.2.253'
	option lookup 'exvpn'

config rule
	option in 'lan'
	option src '192.168.2.254'
	option lookup 'exvpn'

jow · August 21, 2018, 12:27pm

Hm interesting, did you leave the entry in /etc/iproute2/rt_tables in place? Can you try replacing exvpn with a numeric table indexm, e.g. 10 ?

otnert · August 21, 2018, 12:38pm

I've removed all entries in the /etc/rc.local and yes I commented out the # 10 exvpn section of /etc/iproute2/rt_tables.

As in option table '10' ?

Or should I re-enter the 10 exvpn back into /etc/iproute2/rt_tables?

jow · August 21, 2018, 12:40pm

Ah, thats the problem then - sorry for not being clear about that. While you can encode rules and routes (with references to symbolic table names) in /e/c/network you still need to keep the actual name definition in /etc/iproute2/rt_tables. So add that 10 exvpn line back there and it should work - or alternatively - replace all occurrences of exvpn with 10 to avoid the need for that extra definition in an external file.

otnert · August 21, 2018, 12:43pm

rebooting now BRB!

otnert · August 21, 2018, 12:58pm

Looks like the reserved and DHCP allocated IPs are getting the ISP allocated IP. Normally the DHCP IP's should get the VPN IP.

root@LEDE:~# ip -4 rule
0:      from all lookup local
1:      from all iif br-lan lookup exvpn
2:      from all iif br-lan lookup exvpn
3:      from all iif br-lan lookup exvpn
4:      from all iif br-lan lookup exvpn
5:      from all iif br-lan lookup exvpn
32766:  from all lookup main
32767:  from all lookup default

Should I have also taken out this section, now that I have the 10 exvpn in /etc/iproute2/rt_tables?

config route
	option interface 'wan'
	option target '0.0.0.0'
	option netmask '0.0.0.0'
	option gateway '192.168.10.1'
	option table 'exvpn'

jow · August 21, 2018, 1:02pm

Ah the source IP attribute was not used, possibly my mistake. Replace all option src 192.168.2.25x with option src 192.168.2.25x/32 (add /32 at the end).

Nope, that section is defining the extra default route.

otnert · August 21, 2018, 1:07pm

Rebooting BRB!

otnert · August 21, 2018, 1:17pm

OK, I've tested 1x static IP and it's bypassing the VPN, and also tested 1x DHCP address which is using the VPN IP address!

root@LEDE:~# ip -4 rule
0:      from all lookup local
1:      from 192.168.2.250 iif br-lan lookup exvpn
2:      from 192.168.2.251 iif br-lan lookup exvpn
3:      from 192.168.2.252 iif br-lan lookup exvpn
4:      from 192.168.2.253 iif br-lan lookup exvpn
5:      from 192.168.2.254 iif br-lan lookup exvpn
32766:  from all lookup main
32767:  from all lookup default

root@LEDE:~# ip -4 route show table all
default via 192.168.10.1 dev eth0  table exvpn  proto static
0.0.0.0/1 via 10.86.10.5 dev tun0
default via 192.168.10.1 dev eth0  proto static  src 192.168.10.4
8.8.4.4 via 192.168.2.1 dev br-lan  proto static  metric 2
8.8.8.8 via 192.168.2.1 dev br-lan  proto static  metric 2
10.86.10.1 via 10.86.10.5 dev tun0
10.86.10.5 dev tun0  proto kernel  scope link  src 10.86.10.6
128.0.0.0/1 via 10.86.10.5 dev tun0
168.1.112.113 via 192.168.10.1 dev eth0
192.168.2.0/24 dev br-lan  proto kernel  scope link  src 192.168.2.1
192.168.3.0/24 dev br-guest  proto kernel  scope link  src 192.168.3.1
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.4
192.168.10.1 dev eth0  proto static  scope link  src 192.168.10.4
local 10.86.10.6 dev tun0  table local  proto kernel  scope host  src 10.86.10.6
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1
broadcast 192.168.2.0 dev br-lan  table local  proto kernel  scope link  src 192.168.2.1
local 192.168.2.1 dev br-lan  table local  proto kernel  scope host  src 192.168.2.1
broadcast 192.168.2.255 dev br-lan  table local  proto kernel  scope link  src 192.168.2.1
broadcast 192.168.3.0 dev br-guest  table local  proto kernel  scope link  src 192.168.3.1
local 192.168.3.1 dev br-guest  table local  proto kernel  scope host  src 192.168.3.1
broadcast 192.168.3.255 dev br-guest  table local  proto kernel  scope link  src 192.168.3.1
broadcast 192.168.10.0 dev eth0  table local  proto kernel  scope link  src 192.168.10.4
local 192.168.10.4 dev eth0  table local  proto kernel  scope host  src 192.168.10.4
broadcast 192.168.10.255 dev eth0  table local  proto kernel  scope link  src 192.168.10.4

otnert · August 21, 2018, 1:32pm

So I've gone and checked if the 2x static routes work, and I'm in a similar situation.....i.e.

....even though they are defined in /etc/config/network

	option interface 'lan'
	option target '8.8.8.8'
	option netmask '255.255.255.255'
	option gateway '192.168.2.1'
	option metric '2'

config route
	option interface 'lan'
	option target '8.8.4.4'
	option netmask '255.255.255.255'
	option gateway '192.168.2.1'
	option metric '2'

jow · August 21, 2018, 1:36pm

What do you intend to achieve with these routes? Since the router itself is 192.168.2.1 it does not make much sense to have these, essentially looping traffic to itself.

Do you mean to intercept traffic to 8.8.8.8 / 8.8.4.4 and forcibly direct it to the local dnsamsq?

otnert · August 21, 2018, 1:53pm

The 2x google static routes (plus more) are to block devices from using that address, and others I haven't mentioned as it was easier to work with these ATM to prove there is a problem with static routes over the exvpn table.

Reason for static routes:
by segregating the 5x IP's, in effect to use the ISP IP address via the exvpn route, they are used to access US Netflix (here in Australia). Without my local ISP IP address, Netflix will recognize the VPN IP and it won't let me view Netflix here.

I use a SmartDNS Proxy service that requires just short of 10x static routes to utilize their service, and for some reason on these 5x exvpn IP addresses the static routes seem to be bypassed ATM.

jow · August 21, 2018, 1:57pm

Hm, I do not fully understand...

Do you want to block access to these IPs entirely?
Do you want to block access to these IPs for VPN devices?
Do you want to block access to these IPs for non-VPN (192.168.2.25x) devices?
Do you want traffic to these IPs use the VPN?
Do you want traffic to these IPs to not use the VPN?

otnert · August 21, 2018, 2:13pm

no
no
it depends
no
yes

The SmartDNS proxy provider requires customers to use static routes with their service.

see section 4.

here's one static route example:
Network Address: 45.57.0.0
Subnet Mask: 255.255.128.0 (or /17)
Gateway: (use the IP address of your router)

jow · August 21, 2018, 2:15pm

That helps, in this case remove these special routes but add varied rules instead:

config rule
	option in 'lan'           # came via (br-)lan
	option dest '8.8.8.8/32'  # directed to 8.8.8.8
	option lookup 'exvpn'     # divert to exvpn route table to use the non-vpn default route

otnert · August 21, 2018, 2:19pm

I just keep the last comment in the back of my mind for the moment, but consider the example I mentioned earlier i.e.

If I used iptables -I FORWARD -d 45.57.0.0/255.255.128.0 -j REJECT wouldn't this be an equivalent? ...taking the place of the static route.

jow · August 21, 2018, 2:21pm

If the objective is to completely prevent communication with 45.57.0.0/17 then yes, it would be equivalent. But what it will not do is redirecting such traffic to other destinations.

otnert · August 21, 2018, 2:28pm

The reason I mentioned the iptables is if I'm utilizing the exvpn IP, it seems to do the job

e.g in the google static route example, a ping will receive a .Reply from 192.168.2.1: Destination host unreachable

whereas:
utilizing static routes on the exvpn IP lets them reply

That makes sense or should I try and add varied rules instead?

jow · August 21, 2018, 2:32pm

The problem is that on the 192.168.2.1 host you're installing a route stating that a resource is available via the 192.168.2.1 host - this cannot work and will lead to the destination host unreachable error you see.

Such routes generally only make sense when they utilize a gateway on another host, means a gateway IP that is not bound to any local interface of the router itself.

So, if you want to completely deny traffic to such destinations, use an iptables REJECT rule. If you want traffic to these destinations to bypass the VPN, use a varied rule instead.

otnert · August 21, 2018, 2:36pm

Before getting on here tonight, I completely removed all references to exvpn table and routes, disabled the VPN so I could see if the static routes worked, they did.

I don't know the reason as to why they don't work when using the exvpn table?