Topic: OpenVPN connected but traffic not routable

The content of this topic has been archived between 19 Apr 2018 and 30 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Page 1 of 2

Post #1

goldy

17 Sep 2017, 17:20

Internet -> Main Router (192.168.1.1) <- Ethernet -> Open WRT (Dlink DSL 2750U) 192.168.1.98

New to the world of OpenWrt. Using Dlink DSL 2750U, got it flashed with latest 15.05.1 chaos calmer. Able to setup successfully OpenVPN as per the steps at openwrt tutorials at nordvpn site.

I can see vpn tunnel to be running, but when I connect my wireless devices with dlink router, traffic is not routable from vpn tunnel. It is going normally to the internet. Following are the configs. Where I could be wrong?

root@OpenWrt:/etc/config# cat 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 'fd9b:a069:030c::/48'

config interface 'lan'
        option ifname 'eth0.1'
        option force_link '1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.1.98'
        option gateway '192.168.1.1'
        option dns '192.168.1.1'
        option type 'bridge'

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

config switch_vlan
        option device 'eth0'
        option vlan '1'
        option ports '0 1 2 3 8t'

config interface 'nordvpntun'
        option ifname 'tun0'
        option _orig_ifname 'tun0 wlan0'
        option _orig_bridge 'true'
        option proto 'none'

Routes

root@OpenWrt:/etc/config# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 br-lan
10.7.7.0        *               255.255.255.0   U     0      0        0 tun0
1xx.5x.5x.9x    192.168.1.1     255.255.255.255 UGH   0      0        0 br-lan
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan

Firewall

root@OpenWrt:/etc/config# cat firewall

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fe80::/10'
        option src_port '547'
        option dest_ip 'fe80::/10'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config include
        option path '/etc/firewall.user'

config rule
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config zone
        option name 'vpnfirewall'
        option input 'REJECT'
        option output 'ACCEPT'
        option masq '1'
        option mtu_fix '1'
        list network 'nordvpntun'
        option forward 'REJECT'

config forwarding
        option src 'lan'
        option dest 'vpnfirewall'

There is no wan interface.

root@OpenWrt:/etc# ifconfig
br-lan    Link encap:Ethernet  HWaddr
          inet addr:192.168.1.98  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fd9b:a069:30c::1/60 Scope:Global
          inet6 addr: fe80::aef1:dfff:fee7:f930/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:49604 errors:0 dropped:0 overruns:0 frame:0
          TX packets:39928 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:5990081 (5.7 MiB)  TX bytes:8667271 (8.2 MiB)

eth0      Link encap:Ethernet  HWaddr
          inet6 addr: fe80::aef1:dfff:fee7:f930/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:119864 errors:0 dropped:19 overruns:0 frame:0
          TX packets:97347 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:25868113 (24.6 MiB)  TX bytes:22216057 (21.1 MiB)

eth0.1    Link encap:Ethernet  HWaddr
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:62430 errors:0 dropped:0 overruns:0 frame:0
          TX packets:50035 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:14046107 (13.3 MiB)  TX bytes:10168170 (9.6 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:3923 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3923 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:270342 (264.0 KiB)  TX bytes:270342 (264.0 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.7.7.83  P-t-P:10.7.7.83  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:836 (836.0 B)  TX bytes:912 (912.0 B)

wlan0     Link encap:Ethernet  HWaddr
          inet6 addr: fe80::aef1:dfff:fee7:f931/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7217 errors:0 dropped:0 overruns:0 frame:0
          TX packets:21026 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1059594 (1.0 MiB)  TX bytes:8387712 (7.9 MiB)

Post #2

Antek

17 Sep 2017, 20:30

goldy wrote:

I can see vpn tunnel to be running, but when I connect my wireless devices with dlink router, traffic is not routable from vpn tunnel. It is going normally to the internet. Following are the configs. Where I could be wrong?

What exactly do you mean by "not routable from vpn tunnel"? Do you mean that if a host on the other end of the VPN tunnel tries to initiate a connection to a host that is found from your LAN network, then that attempt does not succeed? Or do you mean something else?

I see two potential problems in your configuration. The first is that you do not have a logical network called 'wan' defined in your network configuration file. Despite this, you do have a firewall zone called 'wan' defined in the firewall configuration file, and this zone is associated with the logical networks 'wan' and 'wan6'. Your firewall configuration file also has several inbound rules associated with the 'wan' firewall zone. Since the logical networks associated with the zone do not exist, your firewall configuration file is invalid, in a sense. Perhaps the firewall configuration is not being applied correctly because of this? Maybe try commenting out the offending configuration snippets?

The second potential problem is that you have a one-way forwarding rule from 'lan' to 'vpntunnel', but you do not have the corresponding reverse rule i.e. from 'vpntunnel' to 'lan'. Perhaps you should try adding such a rule, and see if that solves your problem?

Post #3

goldy

18 Sep 2017, 19:30

Antek wrote:

What exactly do you mean by "not routable from vpn tunnel"? Do you mean that if a host on the other end of the VPN tunnel tries to initiate a connection to a host that is found from your LAN network, then that attempt does not succeed? Or do you mean something else?

I meant, from "not routable from vpntunnel" is that, when I connect my laptop with wifi with the Dlink router (openwrt one), the traffic does not go through tun0. It goes through main router and then normally to the internet as any other packet, as if, no vpn is connected. This defeats my purpose, of making all wifi devices to go through vpn tunnel

Antek wrote:

I see two potential problems in your configuration. The first is that you do not have a logical network called 'wan' defined in your network configuration file. Despite this, you do have a firewall zone called 'wan' defined in the firewall configuration file, and this zone is associated with the logical networks 'wan' and 'wan6'. Your firewall configuration file also has several inbound rules associated with the 'wan' firewall zone. Since the logical networks associated with the zone do not exist, your firewall configuration file is invalid, in a sense. Perhaps the firewall configuration is not being applied correctly because of this? Maybe try commenting out the offending configuration snippets?
The second potential problem is that you have a one-way forwarding rule from 'lan' to 'vpntunnel', but you do not have the corresponding reverse rule i.e. from 'vpntunnel' to 'lan'. Perhaps you should try adding such a rule, and see if that solves your problem?

From the user interface deleted the wan firewall zone, so all rules in the firewall got deleted. This DLink DSL2750U does not have any physical wan interface. It has ADSL port (not supported by openwrt) and 4 lan ports. One of the port is being used to connect to main router.

Also added the reverse rule as suggested. But I do not see any change in the behaviour of the network. Still, all data from wifi devices is not going through the tunnel.

New firewall rules :-

root@OpenWrt:~# cat /etc/config/firewall

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config include
        option path '/etc/firewall.user'

config zone
        option name 'vpnfirewall'
        option output 'ACCEPT'
        list network 'nordvpntun'
        option input 'ACCEPT'
        option forward 'ACCEPT'

config forwarding
        option dest 'lan'
        option src 'vpnfirewall'

config forwarding
        option dest 'vpnfirewall'
        option src 'lan'

(Last edited by goldy on 18 Sep 2017, 19:44)

Post #4

Antek

18 Sep 2017, 20:37

Ok, now I understand your problem.

Usually in an OpenVPN setup, the server end uses the "push route" command, which causes the client to create one or more routing table entries for subnets that are found from beyond the tunnel.

The server can also use the 'redirect-gateway def1' command in order to instruct the client to update its default route in the routing table so it points through the VPN tunnel.

To ensure that your client is respecting these routes (and the potential 'redirect-gateway def1' instruction), check that your OpenVPN client configuration file (/etc/config/openvpn) does not have 'route_nopull' option. If set, this option causes the client to ignore the potential routes pushed by the server.

Most OpenVPN servers use these commands, so you might want to check with your VPN service provider to ensure that these commands are sent in the first place. If the commands are sent, then you might need to increase the metric value of the gateway that is configured to the 'lan' logical network. To do so, adjust your network configuration file as follows:

config interface 'lan'
        option ifname 'eth0.1'
        option force_link '1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.1.98'
        option gateway '192.168.1.1'
        option metric '10'                # Set the metric value of this gateway to 10
        option dns '192.168.1.1'
        option type 'bridge'

Try with these changes first, and see if the default route gets set correctly when the VPN tunnel is established. Also, make sure that the default route gets changed back when you drop the VPN tunnel.

If, for some reason, the server does not send the 'redirect-gateway def1' instruction, or does not push the route entries, then you can manually add them by using the 'option route' in your OpenVPN configuration file.

For example, in order to create a default route entry that points through the tunnel, an option such as the following needs to be added:

    ... other config ...
    option route '0.0.0.0 0.0.0.0'

The option value consists of an IP address and a netmask.

Adding this option also requires that you adjust the metric value of the other gateway in your network configuration file. I do not know if it is possible to configure gateway address or its metric value into this option.

Post #5

goldy

20 Sep 2017, 15:42

/etc/config/openvpn is a default configuration file. I have not touched it, instead following file was created which openvpn picks it by itself

root@OpenWrt:~# cat /etc/openvpn/in3.nordvpn.com.tcp443.conf


#           _   _               ___     ______  _   _
#          | \ | | ___  _ __ __| \ \   / /  _ \| \ | |
#          |  \| |/ _ \| '__/ _` |\ \ / /| |_) |  \| |
#          | |\  | (_) | | | (_| | \ V / |  __/| |\  |
#          |_| \_|\___/|_|  \__,_|  \_/  |_|   |_| \_|
#


client
dev tun
proto tcp
remote 137.59.52.98 443
resolv-retry infinite
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping 15
ping-restart 0
ping-timer-rem
reneg-sec 0

remote-cert-tls server

#mute 10000
auth-user-pass secret

comp-lzo
verb 3
pull
fast-io
cipher AES-256-CBC

key-direction 1
ca ca.crt
tls-auth ta.key 1

Asking from the VPN provider didn't help much, didn't get the reply. So if I am assume, they must be sending 'redirect-gateway def1' instruction, then following are the routes before and after tunnel initiation, independent of metric '10' value. Whether I set metric value or not, routes before and after tunnel initiation remains same as below.

Before starting the tunnel.

root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    10     0        0 br-lan
192.168.1.0     *               255.255.255.0   U     10     0        0 br-lan

After starting the tunnel

root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.7.7.1        128.0.0.0       UG    0      0        0 tun0
default         192.168.1.1     0.0.0.0         UG    10     0        0 br-lan
10.7.7.0        *               255.255.255.0   U     0      0        0 tun0
128.0.0.0       10.7.7.1        128.0.0.0       UG    0      0        0 tun0
137.59.52.98    192.168.1.1     255.255.255.255 UGH   0      0        0 br-lan
192.168.1.0     *               255.255.255.0   U     10     0        0 br-lan

Since I am not using openvpn configuration file, then how to set the 'option route' settings ?

Post #6

Antek

20 Sep 2017, 17:51

The 'pull' option is present in your OpenVPN configuration file, hence potential routes sent by the server are respected.

In order to add routes directly to the OpenVPN configuration file, use an entry such as 'route <ip addr> <netmask>'. For reference, you can use the OpenVPN man-pages: https://openvpn.net/index.php/open-sour … npage.html. All options added to the configuration file are similar to their command-line variants, only with the leading double-dashes omitted.

The routing table output shows that a new default route was added when the tunnel is up, and that it's metric value is now lower than that of the default route through 'br-lan'. The server is using 'redirect-gateway def1' command. This is apparent from the genmask value, and the fact that the previous default route doesn't get removed.

However, even with these changes, the packets are not routed correctly through the tunnel? What means do you use to verify the behavior?

Post #7

goldy

20 Sep 2017, 18:16

I connect a device via WiFi to the Dlink router running openwrt and open in the browser, either whatismyip.com or ipleak.net

Post #8

Antek

20 Sep 2017, 20:20

The following option, when placed to your OpenVPN config file, should create a default route through the VPN remote endpoint with a metric value of 0.

route 0.0.0.0 0.0.0.0 vpn_gateway 0

It is a bit uncertain whether the 'vpn_gateway' will be resolved correctly. But give it a spin, and see what the routing table looks like with this change.

Note that this option most likely wipes the previous default route through 'br-lan', so setting up, and then tearing down the VPN tunnel might leave your router without a default routing table entry. Proceed with care.

Post #9

goldy

21 Sep 2017, 20:29

Added this option in OpenVPN config file, and the route changed as follows :

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.7.7.1        128.0.0.0       UG    0      0        0 tun0
default         10.7.7.1        0.0.0.0         UG    0      0        0 tun0
default         192.168.1.1     0.0.0.0         UG    0      0        0 br-lan
10.7.7.0        *               255.255.255.0   U     0      0        0 tun0
128.0.0.0       10.7.7.1        128.0.0.0       UG    0      0        0 tun0
137.59.52.98    192.168.1.1     255.255.255.255 UGH   0      0        0 br-lan
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan

But still it would not help.

By the way, made a discovery, when I try to access internet from the OpenWRT command line, traffic goes via tunnel. Verified this by calling HTTPbin.org/ip website via wget, received VPN IP in response when connected to tunnel and received my original IP when tunnel was disconnected. So basically, LAN ports and WLAN doesn't respect the routing table of openwrt.

Could it be due to the fact, that the main router provides DHCP services and WLAN of openwrt router is bridged to LAN, so routing table of main router is being followed? Or if not, what else could be the mystery?

Post #10

Antek

21 Sep 2017, 22:25

Looks like adding the 'route' option doesn't solve it, so you can take it out of the configuration file.

You are correct about the bridging scenario. When the main router provides a DHCP service then you cannot route all traffic through the VPN tunnel: the DHCP renew messages would get lost, and your wireless clients would likely lose network connectivity altogether when the tunnel is up.

You might achieve a transparent wireless bridge/VPN -setup by using a TAP interface, but I doubt the NordVPN service provider allows this.

To achieve your primary goal, I suggest you change your network layout a little bit: choose one of the LAN ports on the OpenWRT router, and create a new VLAN on this port. Create a new logical network on this virtual adapter, name it "WAN" and have it use a DHCP client. The main router will provide this address. Add a new firewall zone for this logical network, and allow all traffic.

Now, re-enable DHCP service on the "LAN" logical network of the OpenWRT router, and change the statically assigned address to something else than what the primary router is using.

Here are a few configuration files to give you the general idea. They are based on your current configuration, but with the above adjustments:

root@OpenWrt:/etc/config# cat 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 'fd9b:a069:030c::/48'

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

# Added a new VLAN on port 0
config switch_vlan
        option device 'eth0'
        option vlan '1'
        option ports '0 8t'

config switch_vlan
        option device 'eth0'
        option vlan '2'              # Adjusted the second VLAN's ordinal number
        option ports '1 2 3 8t'      # Remove port 0 from here

# Added a new interface
config interface 'wan'
        option ifname 'eth0.1'
        option proto 'dhcp'

config interface 'lan'
        option ifname 'eth0.2'    # Adjusted the VLAN number to match
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.2.1'  # Altered the network address so it differs from primary router's
        option type 'bridge'

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

----

root@OpenWrt:~# cat /etc/config/firewall

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

# Added a new zone, with masquerading
config zone
        option name 'wan'
        list network 'wan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option masq '1'
        option mtu_fix '1'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config include
        option path '/etc/firewall.user'

config zone
        option name 'vpnfirewall'
        list network 'nordvpntun'
        option output 'ACCEPT'
        option input 'ACCEPT'
        option forward 'ACCEPT'
        option masq '1'        # Remove if remote network hosts do not need to communicate with hosts in 'lan'

# Remove this rule if remote network hosts do not need to communicate with hosts in 'lan'
config forwarding
        option dest 'lan'
        option src 'vpnfirewall'

config forwarding
        option dest 'vpnfirewall'
        option src 'lan'

# Added a new forwarding rule; allows Internet access when the tunnel is down
config forwarding
        option src 'lan'
        option dest 'wan'

You did not post your DHCP configuration file, so I cannot write an example for it. But if you look at the OpenWRT DHCP Wiki page, you should figure out how to configure the DHCP pools accordingly. Ignore the pool on 'wan' logical network, and enable it on 'lan', using suitable values. Remember to ensure that 'dnsmasq' daemon is enabled and running; it provides the DHCP service on the OpenWRT router

I wrote these two examples at the dead of night, so remember to check for typos and other subtleties if you intend to use them

Post #11

goldy

22 Sep 2017, 18:39

Thanks a lot, at last it worked with exact these configs provided by you. After so many days of troubleshooting and struggling with openwrt, learned hell lot of things about routing and openwrt. I really appreciate your help.

For others, to view in future, following DHCP config I applied at OpenWRT router :-

root@OpenWrt:~# cat /etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option nonegcache '0'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.auto'
        option localservice '1'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option ra server
        option dhcpv6 server

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'

config dhcp 'nordvpntun'
        option interface 'nordvpntun'
        option ignore '1'

Post #12

Antek

23 Sep 2017, 07:57

You're welcome. Glad I was able to help

Post #13

goldy

26 Feb 2018, 19:39

An extended query to above. This Dlink router hardware is not good enough and VPN traffic is not fast enough due to high computational requirements of encryption involved. So is it possible to offload this VPN heavy workload to a machine connected to this router via ethernet? How shall the network be tweaked on openwrt and the machine?

Post #14

ulmwind

3 Mar 2018, 14:14

goldy, sorry, don't understand your question clearly. Do you want to run client or server instance of OpenVPN?

Post #15

goldy

8 Mar 2018, 16:29

Client instance. I was running it on the dlink but now want to offload it to a machine connected to the same dlink router. So just want to figure out, how network configurations should be in place, so that all traffic of dlink router goes through the machine, where vpn client is running.

Post #16

600cc

10 Mar 2018, 14:44

Yes, you can set up a separate computer to be the VPN endpoint, and send your LAN traffic through it so that it goes out of tun0. Your computer can have a single NIC, or it can have multiple NICs. A single-NIC instance is known as a "hairpin", or "router on a stick". Those terms might help you in your searches.

Here's how to get it to work:

Decide which devices must use the VPN
Configure your network so that those devices use the VPN computer as their default gateway.
Configure the VPN computer to forward traffic from those devices through tun0.
Configure the VPN computer's default gateway to be the D-Link router.
If the VPN computer is running a filter/firewall (e.g. iptables) then configure it to allow traffic forwarding. Remember that the LAN and WAN zones will be different, even with a single NIC. You must create two logical interfaces, one for each zone.

(Last edited by 600cc on 10 Mar 2018, 18:37)

Post #17

goldy

22 Mar 2018, 20:03

Thanks, router-on-a-stick term did help. But before that I had to learn a lot on VLAN stuff.

Now somehow I have been able to setup the network as you suggested, by creating a new vlan3 for traffic from VPN computer's 2nd interface back to D-link router(as gateway=192.168.3.1). Devices connected to vlan 2 use VPN computer as gateway but can't connect to internet or VPN. Internet and 192.168.1.0/24 are reachable from VPN computer.

On VPN computer, net.ipv4.ip_forward=1 and iptables is blank with no rules and default policy to accept on input, output and forward in filter table.

1. What is missing here? Devices on 192.168.2.0/24 are able to reach 192.168.3.x (VPN computer 2nd interface) but not 192.168.3.0/24 or internet.
2. Do I really require 3 VLANs? Is there any scope of optimization without creating complexity?

Post #18

600cc

22 Mar 2018, 22:27

If you're looking to force the network path used by other people's computers, then you will need multiple VLANs, otherwise what's to stop the other users from getting wise and switching gateways?

If you're the only user, you can get away with two VLANs, but you might find it's a bit more complex than you were expecting. You can have both of the VPN computer's NICs in the same VLAN/subnet. It requires paying some attention to routing tables and iptables, but it's possible. Frankly, I'd go for a serial approach, with three VLANs (the WAN interface of one device connects to the LAN interface of the next device, and so on), instead of trying to be clever with same-subnet routing. It's easier.

I recently wanted to know about using specific interfaces for specific traffic, and this post - https://forum.openwrt.org/viewtopic.php … 38#p373938 - contains a link to a StackExchange page which helped me. It might help you, too, if you do decide to play with same-subnet routing.

For example, Internet router (D-Link) IP address: 192.168.2.1
VPN computer "output" IP address: 192.168.2.2
VPN computer "input" IP address: 192.168.2.3

Tell your computers to use 192.168.2.3 as their default gateway, and they'll shunt all their traffic at the VPN computer. Then the VPN computer can handle the VPN tunnel and routing needed.

What are the outputs from the following commands, run on the VPN computer?
* ifconfig -a
* route -n
* ps -ef | grep openvpn

(Last edited by 600cc on 22 Mar 2018, 22:30)

Post #19

goldy

23 Mar 2018, 16:01

Openvpn process is running and tunnel is running fine. Browsing on VPN computer goes through the VPN tunnel. ens160 is lan side and ens224 is wan side of VPN computer.

ifconfig -a
ens160    Link encap:Ethernet  HWaddr 00:0c:29:15:a3:a6  
          inet addr:192.168.2.212  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::3d15:3d3:a47b:bad8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4606 errors:0 dropped:0 overruns:0 frame:0
          TX packets:764 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:356606 (356.6 KB)  TX bytes:76827 (76.8 KB)

ens224    Link encap:Ethernet  HWaddr 00:0c:29:15:a3:b0  
          inet addr:192.168.3.222  Bcast:192.168.3.255  Mask:255.255.255.0
          inet6 addr: fe80::e3bd:3ac0:69:c6c5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7446 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8185 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:5451814 (5.4 MB)  TX bytes:1404920 (1.4 MB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:2549 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2549 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:786534 (786.5 KB)  TX bytes:786534 (786.5 KB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.15.0.4  P-t-P:10.15.0.4  Mask:255.255.0.0
          inet6 addr: fdda:d0d0:cafe:1301::1002/64 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:6474 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7091 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:4076423 (4.0 MB)  TX bytes:695784 (695.7 KB)

xx.xx.xx.xx is the VPN provider's address hard coded in the openvpn config file
192.168.2.212 is provided by DHCP server running at 192.168.2.1 (DLink Router) as gateway to all devices including VPN computer.

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.15.0.1       128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.3.1     0.0.0.0         UG    100    0        0 ens224
0.0.0.0         192.168.2.212   0.0.0.0         UG    101    0        0 ens160
10.15.0.0       0.0.0.0         255.255.0.0     U     0      0        0 tun0
xx.xx.xx.xx    192.168.3.1     255.255.255.255 UGH   0      0        0 ens224
128.0.0.0       10.15.0.1       128.0.0.0       UG    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 ens160
192.168.2.0     0.0.0.0         255.255.255.0   U     100    0        0 ens160
192.168.3.0     0.0.0.0         255.255.255.0   U     100    0        0 ens224

And god knows what 169.254.0.0 entry is ? :-)

Post #20

600cc

24 Mar 2018, 02:17

goldy wrote:

ens160 is lan side and ens224 is wan side of VPN computer.

That might be part of the problem, judging by the config you posted.

If your VPN computer can reach the D-Link router (and the other end of the VPN tunnel), it should be doing so from its own WAN interface, not its LAN interface. That's not a technical limitation, but a conceptual one; it can help to distinguish between LAN and WAN when trying to work out device behaviour.

It makes connections from its WAN; it accepts connections into its LAN.

The other thing which is curious, is the gateway shown by your VPN computer's routing table. Your VPN computer appears to be connecting through a gateway at 192.168.3.1, but it's not immediately obvious which device has that IP address. Is that a secondary address on your D-Link router?

goldy wrote:

And god knows what 169.254.0.0 entry is ? :-)

https://en.wikipedia.org/wiki/Link-local_address#IPv4

Post #21

goldy

24 Mar 2018, 10:20

600cc wrote:

If your VPN computer can reach the D-Link router (and the other end of the VPN tunnel), it should be doing so from its own WAN interface, not its LAN interface. That's not a technical limitation, but a conceptual one; it can help to distinguish between LAN and WAN when trying to work out device behaviour.

Isn't it already doing? That's why tunnel was able to run. VPN computer is able to reach DLink at 192.168.3.1 and further to 192.168.1.1(internet main router)

600cc wrote:

It makes connections from its WAN; it accepts connections into its LAN.

From WAN, connections seems to work fine. I doubt from the LAN side, if it is able to accept that. Do you think routing is fine? And shouldn't blank iptables allow everything or should I explicitly add some rule in Forward chain?

600cc wrote:

The other thing which is curious, is the gateway shown by your VPN computer's routing table. Your VPN computer appears to be connecting through a gateway at 192.168.3.1, but it's not immediately obvious which device has that IP address. Is that a secondary address on your D-Link router?

Yes.
Following is the Dlink ifconfig

root@OpenWrt:~# ifconfig
br-lan    Link encap:Ethernet  HWaddr AC:F1:DF:E7:F9:30
          inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fd9b:a069:30c:10::1/60 Scope:Global
          inet6 addr: fe80::aef1:dfff:fee7:f930/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:476730 errors:0 dropped:168 overruns:0 frame:0
          TX packets:600672 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:44361336 (42.3 MiB)  TX bytes:540052981 (515.0 MiB)

eth0      Link encap:Ethernet  HWaddr AC:F1:DF:E7:F9:30
          inet6 addr: fe80::aef1:dfff:fee7:f930/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3872819 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3182721 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3058062997 (2.8 GiB)  TX bytes:1557080793 (1.4 GiB)

eth0.1    Link encap:Ethernet  HWaddr AC:F1:DF:E7:F9:30
          inet addr:192.168.1.98  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::aef1:dfff:fee7:f930/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1107290 errors:0 dropped:0 overruns:0 frame:0
          TX packets:555352 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:816216668 (778.4 MiB)  TX bytes:80253943 (76.5 MiB)

eth0.2    Link encap:Ethernet  HWaddr AC:F1:DF:E7:F9:30
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1586832 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1359298 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1545826744 (1.4 GiB)  TX bytes:152414758 (145.3 MiB)

eth0.3    Link encap:Ethernet  HWaddr AC:F1:DF:E7:F9:30
          inet addr:192.168.3.1  Bcast:192.168.3.255  Mask:255.255.255.0
          inet6 addr: fd9b:a069:30c::1/64 Scope:Global
          inet6 addr: fe80::aef1:dfff:fee7:f930/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:256788 errors:0 dropped:130 overruns:0 frame:0
          TX packets:254804 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:44014322 (41.9 MiB)  TX bytes:289030038 (275.6 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:29619 errors:0 dropped:0 overruns:0 frame:0
          TX packets:29619 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2273241 (2.1 MiB)  TX bytes:2273241 (2.1 MiB)

wlan0     Link encap:Ethernet  HWaddr AC:F1:DF:E7:F9:31
          inet6 addr: fe80::aef1:dfff:fee7:f931/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1719353 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2172530 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:167322740 (159.5 MiB)  TX bytes:2121445733 (1.9 GiB)

Router with 192.168.1.1 is the main internet router. Vlan1 (192.168.1.0/24) connects Dlink to main internet router, Vlan2 (192.168.2.0/24) connects all wlan devices and DLink to VPN computer Lan Interface (ens160), Vlan3 (192.168.3.0/24) connects VPN computer Wan interface (ens224) back to Dlink at 192.168.3.1(eth0.3)

I hope you now have enough clarity on the whole network design.

Post #22

600cc

24 Mar 2018, 12:42

Give me a bit. I'll fish out Visio and knock up a diagram, which might better help to illustrate. When I wrote my post last night, it made perfect sense... to me. Now, after some sleep, I'm struggling to make sense of my words. I know what I want to illustrate, so I'll do just that: illustrate.

Post #23

600cc

24 Mar 2018, 13:24

As promised, here is a diagram which might better help to illustrate. The IP addresses are illustrative only; feel free to change them to suit your needs. But I hope the concept of two subnets (broadcast domains) sharing the same VLAN (collision domain) is clear.

(I'm aware it's not a pretty diagram; I'm a complete novice when it comes to Visio.)

(Last edited by 600cc on 24 Mar 2018, 13:27)

Post #24

goldy

24 Mar 2018, 18:34

Your diagram is pretty clear and understandable. And here is what I have laid out in past few weeks :-

If I compare, the only difference is use of one extra vlan. In the end, both intend to do the same thing. But why things don't work in mine, that's the quest? What is missing in the puzzle?

Post #25

600cc

25 Mar 2018, 11:43

Good question. I've only just had some coffee a few minutes ago, so my brain isn't yet in gear.

To recap, in case I've missed something:
* Your VPN computer can open a VPN connection over its WAN interface (192.168.3.222) to a remote endpoint and can send its own traffic down the tunnel.
* Other devices are configured to use the VPN computer's LAN interface (192.168.2.212) as their default gateway, but are unable to send traffic further.

This might be a really dumb question (and apologies if it is), but are you positive that IPv4 forwarding is enabled in sysctl.conf on the VPN computer?

Also, on the VPN computer, is your iptables filter table completely empty, or does it have rules to permit established/related traffic (in other words, the return traffic triggered by the outbound traffic)?

(Last edited by 600cc on 25 Mar 2018, 11:45)

Page 1 of 2