1

I have bridge created between eth0 & wlan0. Following is ifconfig

root@ubuntu:~ $ ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.24.11.15  netmask 255.255.255.0  broadcast 10.24.11.255
        inet6 fe80::1fd4:f47a:59d2:1de8  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:8e:38:ee  txqueuelen 1000  (Ethernet)
        RX packets 2571  bytes 308138 (300.9 KiB)
        RX errors 0  dropped 230  overruns 0  frame 0
        TX packets 2511  bytes 289807 (283.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether b8:27:eb:db:6d:bb  txqueuelen 1000  (Ethernet)
        RX packets 6268  bytes 1641477 (1.5 MiB)
        RX errors 0  dropped 39  overruns 0  frame 0
        TX packets 7141  bytes 1630895 (1.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 454  bytes 30843 (30.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 454  bytes 30843 (30.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.20.1.226  netmask 255.255.255.224  destination 10.20.1.226
        inet6 fe80::ea4d:bb87:d649:5308  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1407  bytes 94382 (92.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether b8:27:eb:8e:38:ee  txqueuelen 1000  (Ethernet)
        RX packets 5095  bytes 1401614 (1.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5124  bytes 1660553 (1.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Route table :

root@ubuntu:~ $ sudo ip route
0.0.0.0/1 via 10.20.1.225 dev tun0
default via 10.24.11.1 dev br0 src 10.24.11.15 metric 204
10.20.1.224/27 dev tun0 proto kernel scope link src 10.20.1.226
10.24.11.0/24 dev br0 proto kernel scope link src 10.24.11.15 metric 204
52.36.18.24 via 10.24.11.1 dev br0
128.0.0.0/1 via 10.20.1.225 dev tun0

And

root@ubuntu:~ $ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.20.1.225     128.0.0.0       UG    0      0        0 tun0
0.0.0.0         10.24.11.1      0.0.0.0         UG    204    0        0 br0
10.20.1.224     0.0.0.0         255.255.255.224 U     0      0        0 tun0
10.24.11.0      0.0.0.0         255.255.255.0   U     204    0        0 br0
52.36.18.24     10.24.11.1      255.255.255.255 UGH   0      0        0 br0
128.0.0.0       10.20.1.225     128.0.0.0       UG    0      0        0 tun0

Subnet 10.2.0.0/16 is reachable through tunnel tun0 able to ping IP 10.2.1.145 from this box. But not able to ping 10.2.1.145 from the devices connected to this box on wlan0. Also able to ping 10.24.11.15 from devices connected to this box on wlan0

If I perform traceroute 10.2.1.145 devices connected to this box on wlan0, connection goes out through eth0 via public ip.

eth0 has 10.24.11.15, but after creating bridge, it shifted to br0

What route I am missing here to push 10.2.0.0/16 traffic through tun0 ?

Here is the more output :

root@ubuntu:~ $ ip route get 10.2.1.145 from 10.24.11.23 iif br0
10.2.1.145 from 10.24.11.23 via 10.20.0.225 dev tun0
    cache  iif br0

root@ubuntu:~ $ sudo ip netconf show dev tun0
ipv4 dev tun0 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off
root@ubuntu:~ $

root@ubuntu:~ $ sudo ip netconf show dev br0
ipv4 dev br0 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off

Ping from WiFi Client and tcpdump from ubuntu :

root@client:~# ping 10.2.1.145

root@ubuntu:~ $ sudo tcpdump -ni br0 'icmp and ip host 10.2.1.145'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:30:56.903893 IP 10.24.11.23 > 10.2.1.145: ICMP echo request, id 34567, seq 8, length 64
15:30:57.904278 IP 10.24.11.23 > 10.2.1.145: ICMP echo request, id 34567, seq 9, length 64
15:30:58.904826 IP 10.24.11.23 > 10.2.1.145: ICMP echo request, id 34567, seq 10, length 64


root@client:~# ping 10.2.1.145

root@ubuntu:~ $ sudo tcpdump -nei eth0 'icmp and ip host 10.2.1.145'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:26:55.356091 ac:bc:32:bf:ad:57 > 18:b1:69:75:7a:f4, ethertype IPv4 (0x0800), length 98: 10.24.11.147 > 10.2.1.145: ICMP echo request, id 5646, seq 169, length 64

iptables-save :

root@ubuntu:~ $ sudo iptables-save
# Generated by iptables-save v1.6.0 on Mon May  6 15:37:25 2019
*nat
:PREROUTING ACCEPT [1299:221082]
:INPUT ACCEPT [290:32450]
:OUTPUT ACCEPT [4762:319088]
:POSTROUTING ACCEPT [680:45560]
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
# Completed on Mon May  6 15:37:25 2019
root@ubuntu:~ $ uname -a
Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux

root@ubuntu:~ $ sudo ip rule ls
0:  from all lookup local
32766:  from all lookup main
32767:  from all lookup default

root@ubuntu:~ $ sudo ip route ls table all
0.0.0.0/1 via 10.20.2.129 dev tun0
default via 10.24.11.1 dev br0 src 10.24.11.15 metric 204
10.20.2.128/27 dev tun0 proto kernel scope link src 10.20.2.130
10.24.11.0/24 dev br0 proto kernel scope link src 10.24.11.15 metric 204
52.37.118.218 via 10.24.11.1 dev br0
128.0.0.0/1 via 10.20.2.129 dev tun0
broadcast 10.20.2.128 dev tun0 table local proto kernel scope link src 10.20.2.130
local 10.20.2.130 dev tun0 table local proto kernel scope host src 10.20.2.130
broadcast 10.20.2.159 dev tun0 table local proto kernel scope link src 10.20.2.130
broadcast 10.24.11.0 dev br0 table local proto kernel scope link src 10.24.11.15
local 10.24.11.15 dev br0 table local proto kernel scope host src 10.24.11.15
broadcast 10.24.11.255 dev br0 table local proto kernel scope link src 10.24.11.15
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
fe80::/64 dev br0 proto kernel metric 256  pref medium
fe80::/64 dev tun0 proto kernel metric 256  pref medium
local ::1 dev lo table local proto kernel metric 0  pref medium
local fe80::1fd4:f47a:59d2:1de8 dev br0 table local proto kernel metric 0  pref medium
local fe80::54bf:cf69:4385:4b1c dev tun0 table local proto kernel metric 0  pref medium
ff00::/8 dev br0 table local metric 256  pref medium
ff00::/8 dev tun0 table local metric 256  pref medium

root@ubuntu:~ $ sudo ip -4 a ls
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.24.11.15/24 brd 10.24.11.255 scope global br0
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    inet 10.20.2.130/27 brd 10.20.2.159 scope global tun0
       valid_lft forever preferred_lft forever
root@ubuntu:~ $

Other side of the VPN is not openvpn server, because I am trying this with AWS Client VPN Endpoint here. I did run sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE on ubuntu host. Don't have access to VPN server.

Update :

On wifi client

    root@client:~ $ ifconfig
    eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:d2:02:8c  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

     lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

    wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.24.11.201  netmask 255.255.255.0  broadcast 10.24.11.255
        inet6 fe80::f9e2:e7af:ab5f:7865  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:87:57:d9  txqueuelen 1000  (Ethernet)
        RX packets 86  bytes 7978 (7.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 97  bytes 16637 (16.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@client:~ $ ip -4 route list
default via 10.24.11.1 dev wlan0 src 10.24.11.201 metric 303
10.24.11.0/24 dev wlan0 proto kernel scope link src 10.24.11.201 metric 303

I deleted sudo route del default gw 10.24.11.1 wlan0 and added sudo route add default gw 10.24.11.15 wlan0 on wifi client

root@client:~ $ ip -4 route list
default via 10.24.11.15 dev wlan0
10.24.11.0/24 dev wlan0 proto kernel scope link src 10.24.11.201 metric 303

Then tried

root@client:~# ping 10.2.1.145
PING 10.2.1.145 (10.2.1.145): 56 data bytes

root@ubuntu:~ $ sudo tcpdump -ni br0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:40:03.832209 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 614, seq 121, length 64
13:40:04.879329 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 614, seq 122, length 64
13:40:05.911833 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 614, seq 123, length 64

root@ubuntu:~ $ sudo tcpdump -ni tun0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
13:40:49.539044 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 618, seq 1, length 64
13:40:50.553286 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 618, seq 2, length 64
13:40:51.597073 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 618, seq 3, length 64

Ran on Ubuntu

1 iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

2 sudo iptables -A FORWARD -i br0 -o tun0 -j ACCEPT

3 sudo iptables -A FORWARD -i tun0 -o br0 -j ACCEPT

root@ubuntu:~ $ sudo iptables-save -c
# Generated by iptables-save v1.6.0 on Mon May 13 20:30:31 2019
*filter
:INPUT ACCEPT [32:2202]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [49:4174]
[0:0] -A FORWARD -i br0 -o tun0 -j ACCEPT
[0:0] -A FORWARD -i tun0 -o br0 -j ACCEPT
COMMIT
# Completed on Mon May 13 20:30:31 2019
# Generated by iptables-save v1.6.0 on Mon May 13 20:30:31 2019
*nat
:PREROUTING ACCEPT [7:1109]
:INPUT ACCEPT [2:144]
:OUTPUT ACCEPT [20:1340]
:POSTROUTING ACCEPT [4:268]
[0:0] -A POSTROUTING -o eth0 -j MASQUERADE
[16:1072] -A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
# Completed on Mon May 13 20:30:31 2019

root@client:~ $ ping 10.2.1.145
PING 10.2.1.145 (10.2.1.145) 56(84) bytes of data.

root@ubuntu:~ $ sudo iptables-save -c
# Generated by iptables-save v1.6.0 on Mon May 13 20:31:24 2019
*filter
:INPUT ACCEPT [119:7998]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [218:19046]
[0:0] -A FORWARD -i br0 -o tun0 -j ACCEPT
[0:0] -A FORWARD -i tun0 -o br0 -j ACCEPT
COMMIT
# Completed on Mon May 13 20:31:24 2019
# Generated by iptables-save v1.6.0 on Mon May 13 20:31:24 2019
*nat
:PREROUTING ACCEPT [10:1331]
:INPUT ACCEPT [5:366]
:OUTPUT ACCEPT [45:3015]
:POSTROUTING ACCEPT [9:603]
[0:0] -A POSTROUTING -o eth0 -j MASQUERADE
[36:2412] -A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
# Completed on Mon May 13 20:31:24 2019

Then :

root@client:~ $ ping 10.20.1.225

root@ubuntu:~ $ sudo tcpdump -ni br0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:42:07.498023 IP 10.24.11.201 > 10.20.1.225: ICMP echo request, id 15212, seq 208, length 64
09:42:08.537648 IP 10.24.11.201 > 10.20.1.225: ICMP echo request, id 15212, seq 209, length 64
09:42:09.577700 IP 10.24.11.201 > 10.20.1.225: ICMP echo request, id 15212, seq 210, length 64

root@ubuntu:~ $ sudo tcpdump -ni tun0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

and

root@client:~ $ ping 10.2.1.145

root@ubuntu:~ $ sudo tcpdump -ni br0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:43:32.055291 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 15215, seq 12, length 64
09:43:33.099422 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 15215, seq 13, length 64
09:43:34.135264 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 15215, seq 14, length 64

root@ubuntu:~ $ sudo tcpdump -ni tun0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Looks like ICMP echo request packages does not get forwarded to tun0.

  • Seems like forwarding is disabled on br0 interface. Check output of ip netconf show dev br0. – Anton Danilov May 6 at 20:13
  • Hm.. It's a curious case. And it's not disabled forwarding. What kernel version do you use? Check it with uname -a command. Also paste the output of ip rule ls, ip route ls table all and ip -4 a ls. – Anton Danilov May 7 at 6:45
  • I'll build the lab and check your topology. – Anton Danilov May 7 at 17:53
  • I cannot reproduce your issue in the lab. But nevermind. Let's run tcpdump -ni tun0 'icmp' on the ubuntu host. You should see icmp echo request packets from masqueraded address to 10.2.1.145. – Anton Danilov May 7 at 20:00
  • Not for tcpdump -ni tun0 'icmp' but sudo tcpdump -ni br0 'icmp and ip host 10.2.1.145' shows ICMP echo request – roy May 7 at 20:10
3
+25

So, let's try to solve your issue. To better understanding I've drawn the network topology diagram. To clarify what happens, I've splited graphically l2 and l3 processing inside your ubuntu host - it'll help in a further reasoning.

network topology

Check the following steps:

  • Check the routing on the wifi client (here and further - 10.24.11.X - replace to your actual ip address of this device). Your scheme requires either of two posibilites: default route via 10.24.11.15 or better (I think) 10.2.0.0/16 via 10.24.11.15.

  • Check the forwarding on the ubuntu host with ip route get 10.2.1.145 from 10.24.11.X iif br0 and ip route get 10.24.11.X from 10.2.1.145 iif tun0 commands. It should return something like 10.2.1.145 from 10.24.11.X via 10.20.1.225 dev tun0 (valid route). If it returns something like RTNETLINK answers: No route to host, it means you haven't enable the ip forwarding (globally or per interface). Enable it with sysctl command. Also check the forwarding on the tun0 and br0 interfaces with command ip netconf show dev ... (there should be forwarding on string).

  • Run the ping 10.2.1.145 command on the wifi client and run the tcpdump -ni br0 'icmp and ip host 10.24.11.X' and the tcpdump -ni tun0 'icmp' on the ubuntu host. You should see some packets with icmp echo request from the wifi client to 10.2.1.145 host. If you don't see it, check the firewall with iptables-save command (and paste the output into the question to get the help about it for your case). If you see the icmp echo request, but don't see icmp echo reply in the tcpdump, then you need check the remote site.

  • Your scheme also requires some routing setup on the remote side (on the openvpn server). There should be route 10.24.11.0/24 via 10.20.1.226 on the openvpn server itself and the route to same subnet on some remote host through openvpn server. Other way to make the connectivity - using of the NAT on ubuntu host (but it will be described later).

  • On the openvpn server run the ip route get 10.2.1.145 from 10.24.11.X iif tunX and ip route get 10.24.11.X from 10.2.1.145 iif ethZ command (where tunX and ethZ are corresponding interfaces the open vpn server). Both commands should display valid routes otherwise check the enabling of forwarding with ip netconf show command (and enable it with sysctl).

  • Run the tcpdump -ni tunX 'icmp and ip host 10.2.1.145' command on the openvpn server. You should see incoming icmp echo requests from remote wifi client and outgoing icmp echo reply from 10.2.1.145 host. If you don't see the icmp echo reply, run the tcpdump (or the wireshark) on the some remote host and check the firewall settings on it.

  • If you don't have the administrative access to other side and cannot setup the routing on it, then you should use the NAT on the ubuntu host. You should add the next rule in the firewall rule set (better use iptables-save and iptables-apply command for safety):

iptables -t nat -A POSTROUTING \
         -o tun0 \
    -j MASQUERADE
  • Last step is checking of the firewall. Your setup requires allowing the forwarding packets through the ubuntu host. Simplified the rules:
iptables -A FORWARD -i br0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o br0 -j ACCEPT
  • Then check firewall rule counters in the output of the iptables-save -c command. The numbers in square brackets are matching counters of rule in format [packets:bytes]. Restart the ping and check it. At least the NAT rule should be hit. Order of rules is very important!

  • If the steps above haven't helped to solve your issue, please add the additional information into the question, and I'll provide some additional steps to troubleshoot the problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.