RPi Installation + WireGuard

Greetings, I’ve been having a bit of a hell’ish time trying to setup my Raspberry Pi 4 (B) in order to run WireGuard on it (primarily for travel; it being rather small, etc) with the idea of connecting my phone, laptop, etc to the RPi in order for it to function as an Access Point (AP) or a secure WiFi hotspot. Here are some of what I’ve been grappling with and where I’m stuck at the moment,

  1. I followed the OpenWRT webpage to simply install the latest image (OpenWrt 21.02.1) and get it work (no WireGuard involvement yet); this was a fresh install BTW
  2. I connected my WAN ethernet cable to the single port and connected the RPi to a keyboard/screen
  3. I was NOT able to ping anything internal or external
  4. I had to modify the static IP (defaults to 192.168.1.1) to dynamic/dhcp which got my pings to go through
  5. (humble opinion) I'm not a fan of having a dynamic IP address for my router as that, in my limited experience, tends to complicate things needlessly (/humble opinion)
  6. I enabled WiFi and was able to connect to the RPi and all was working (though I had no idea what the RPi’s IP address is in order to muck around with LuCI – ‘ifconfig -a’ on the console gave me that info - this will certainly be a headache moving forward)
  7. So everything was functioning now, the RPi is able to ping things on its own (via console) and is working fine as an AP (ie. WiFi)
  8. I then installed WireGuard following the instructions noted for a client (I’ve done this before) and all the appropriate interfaces seem to have come-up OK; here’s where it gets interesting
  9. I can surf the web just fine from both RPi and my laptop (connected to the RPi’s AP) but my IP isn’t being obfuscated/hidden. Its as though the vpn is not running, but it is.
  10. I ran some debug and I can see, through traceroute, that the wireguard connection is getting established just fine yet I’m at a loss as to what to do next and/or why my IP continues to note my local ISP IP address. I’m including below some “relevant” info below for comment/guidance. I suspect my routing or firewall are messed-up and going through the documentation has only gotten me more confused - argh !

I’d really appreciate any help...

Feel free to ask if I've missed anything relevant or you'd like to see a dump/log of something in particular.

Detailed info and Various Logs

A. Initially, I wanted to get this accomplished - I wasn't able to and so abandoned the effort.

                wifi                         wired             wan   
mobile-phone <~.~.~.~.~> (wlan0)RPi(eth0) <---------> router <-----> INTERNET
            \             /            \              /
           (dhcp)      192.168.10.1   192.168.70.8   192.168.70.1

B. This is the current "working" situation - my issue now is that WireGuard is not working properly.

                               RPi
                wifi    ┌─────bridge───────┐   wired            wan
mobile-phone <.~.~.~.~> │(wlan0) br0 (eth0)│ <-------> router <-----> INTERNET
            \                     |                    / 
           (dhcp                (dhcp                DHCP-server - 192.168.70.1
            from router)         from router - 192.168.70.8)

-- Info - bits from /etc/config/network

 config interface 'vpn'
         option proto 'wireguard'
         option private_key '_REMOVED_'
         list addresses '198.19.3.134/16'
 
 config wireguard_vpn 'wgserver'
         option public_key '_REMOVED_'
         option endpoint_host '23.183.129.11'
         option endpoint_port '32381'
         option route_allowed_ips '1'
         option persistent_keepalive '25'
         list allowed_ips '0.0.0.0/0'
         list allowed_ips '::/0'

-- root@OpenWrt:~# route

Kernel IP routing table
Destination     Gateway       Genmask          Flags Metric Ref Use Iface
default         *             0.0.0.0          U     0      0   0   vpn
23.183.129.11   192.168.70.1  255.255.255.255  UGH   0      0   0   br-lan
192.168.70.0    *             255.255.255.0    U     0      0   0   br-lan
198.19.0.0      *             255.255.0.0      U     0      0   0   vpn

-- root@OpenWrt:~# ip route

default dev vpn scope link
23.183.129.11 via 192.168.70.1 dev br-lan
192.168.70.0/24 dev br-lan scope link  src 192.168.70.8
198.19.0.0/16 dev vpn scope link  src 198.19.3.134

-- root@OpenWrt:~# ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP qlen 1000
    link/ether dc:a6:32:f2:fd:18 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP qlen 1000
    link/ether dc:a6:32:f2:fd:19 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::dea6:32ff:fef2:fd19/64 scope link
       valid_lft forever preferred_lft forever
7: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether dc:a6:32:f2:fd:18 brd ff:ff:ff:ff:ff:ff
    inet 192.168.70.8/24 brd 192.168.70.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fd1c:991c:6ab0::1/60 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::dea6:32ff:fef2:fd18/64 scope link
       valid_lft forever preferred_lft forever
9: vpn: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN qlen 1000
    link/[65534]
    inet 198.19.3.134/16 brd 198.19.255.255 scope global vpn
       valid_lft forever preferred_lft forever

-- root@OpenWrt:~# traceroute google.com

traceroute to google.com (142.250.181.110), 30 hops max, 46 byte packets
 1  198.19.0.1 (198.19.0.1)  260.039 ms  259.998 ms  260.079 ms
 2  v111.ce02.phx-01.us.leaseweb.net (23.183.129.61)  260.962 ms  v111.ce01.phx-01.us.leaseweb.net (23.183.129.60)  260.612 ms  v111.ce02.phx-01.us.leaseweb.net (23.183.129.61)  261.278 ms
 3  ae-1.br01.phx-01.us.leaseweb.net (173.208.127.2)  260.726 ms  be-2.br02.phx-01.us.leaseweb.net (173.208.127.8)  260.070 ms  ae-1.br01.phx-01.us.leaseweb.net (173.208.127.2)  260.056 ms
 4  phx-b1-link.ip.twelve99.net (62.115.165.76)  261.275 ms  261.602 ms  262.867 ms
 5  fjr04s08-in-f14.1e100.net (142.250.181.110)  508.296 ms  508.649 ms  507.425 ms

root@OpenWrt:~# pgrep -f -a wg; wg show; wg showconf vpn

3332 wg-crypt-vpn
3936 kworker/1:2-wg-
3975 kworker/2:1-wg-
interface: vpn
  public key: _REMOVED_
  private key: (hidden)
  listening port: 42055

peer: _REMOVED_
  endpoint: 23.183.129.11:32381
  allowed ips: 0.0.0.0/0, ::/0
  latest handshake: 15 seconds ago
  transfer: 10.68 KiB received, 22.25 KiB sent
  persistent keepalive: every 25 seconds
[Interface]
ListenPort = 42055
PrivateKey = _REMOVED_

[Peer]
PublicKey = _REMOVED_
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = 23.183.129.11:32381
PersistentKeepalive = 25

There is a lot here, but fundamentally, your issue exactly the same as you'll see in this thread. There are solutions in that same thread, too.

I'll comment on some of the other things, too.

This is expected behavior for OpenWrt on the Pi with a fresh install. It is only a single ethernet port which is assigned to the LAN by default. The default state of OpenWrt is such that the LAN has a static IP address of 192.168.1.1 and has the DHCP server enabled -- this allows the OpenWrt device to assign addresses to clients on the LAN as most routers do by default.

You could have also simply modified the IP to a different static address that works on your network (i.e. on the same subnet but not conflicting with any other devices or the DHCP pool). Typically, you should also disable the DHCP server in this case. See info about setting up a dumb AP.

There are many options of how to configure a network device. As I mentioned above, you could have used a different static IP address, or you can also configure your upstream DHCP server with a "DHCP reservation" such that it provides a specific, known, and constant IP address to the Pi. OpenWrt by default has a DHCP client on the WAN interface and a static IP + DHCP server on the LAN -- this is how routers are typically used (although it may be necessary to change the WAN to PPPoE or static IP depending on the ISP).

The Pi (especially the Pi4) makes an excellent wired router (with the addition of a USB3 - ethernet adapter), but it makes a terrible wifi AP. The performance will be poor in this mode when it comes to range and multiple wifi devices simultaneously accessing the network. You are better off with a proper wireless AP.

The rest of your issues (cause and solution options) is in the thread I linked above. Have a read through that and come back with any additional questions.

2 Likes

Thank you @psherman for your attention and reply - much appreciated !

I read the thread noted, followed it's instructions and setup a static IP on my laptop and as you noted all is working as expected - wireguard is doing its job and the vpn is working perfectly fine (ISP IP gone). So that experiment has been successful, what should I do now so that anyone connecting to the AP gets tunneled through the vpn without the need for them to change anything ?

In passing, I do NOT have any control (or even access) to the ISP router; so whatever solution(s) to attempt will need to be in the context of the OpenWRT RPi itself.

(A few thoughts)

  1. I've setup a few OpenWRT routers in the past in the same environment and everything usually makes sense and works with minimal intervention - you have a WAN port, a number of LAN ports, etc, so you end-up with a LAN and a WAN interface (eth0, eth1, etc), blah, blah. With the RPi there is only a single ethernet port (eth0), let's assume I don't want to fiddle with USB-ethernet dongles, and by default that port is being configured as a LAN; my question is why not configure it as a WAN from the get-go which will hopefully realize a network akin to my initial A diagram above ? Let's circumvent what needs to be done by default and maybe focus on what needs to be done now to make diagram A a reality or something similar to get the intended work-around.
  2. On the RPi OpenWRT page someone should add a note on the fact that the RPi is not expected to work, in most instances, requiring manual intervention in the form of setting up dhcp on its one port. I've seen lots of questions on this one topic all over the internet.

(/A few thoughts)

With all of that said, I suspect if we're able to create diagram A above then that would solve this (& other ?) issues. As noted, I don't have control over the ISP router and won't have that access in hotels either so I'll need a solution that will simply work once the RPi is plugged-in. In passing, if all the solutions require me to fiddle with the ISP router, then why are multi-ported devices able to work (thus the "few thoughts" out-loud thinking above) and not the RPi ?

Ideas/Suggestions, Instructions ?

With the assertion that you don’t have the ability to change anything about the upstream router and the requirement that clients must be able to connect and use the dhcp issued configuration, your only option is to assign the Ethernet port to the wan interface (and wan firewall zone) and run the pi as a normal router. This means that the LAN interface must be a static IP address in a different subnet than the upstream router, and you will probably want to reenable the dhcp server on the openwrt pi.

You have also stated that you don’t want to use any Ethernet dongles, so that means that your pi will connect by a wired connection to the upstream network and all of the clients must connect via WiFi.

On the hardware front, you can select from a very large number of routers supported by openwrt that will have good WiFi performance and multiple wired connections to provide you with a wan port and one or more lan ports.

1 Like

Thanks again for your continued involvement !

That's perfectly fine for what I intend to do. :+1:

Fair enough, how do I go about doing that ? Can you show me the required configurations or setup please.

Beyond what is pasted-in above, feel free to let me know if you'd like to see more of my current RPi configuration info and/or state details. I've tried to define my 'br-lan' (eth0) with a static IP of 192.168.10.1 and defining a non-existent WAN dhcp interface but that got me nowhere, it might be that I got the associations wrong and thus the "please show me what it needs to be" request. What should I do to reconfigure the RPi to bring about the intended results ?

Thanks & Regards.

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall

Below you'll find the requested info (thanks !).

My biggest issue, and I'm noting this simply to learn, is that I have a single eth0 which I'll assign to 'wan' but what should I do with the 'lan' (or 'br-lan'), do I delete it, assign it without an 'eth0' (is that even legal/legit ?) or make it "virtual" or ... ? I'm guessing I still need the 'lan' for the wireless interface in order to assign dhcp IP addresses from. I think you see my confusion. Once this is solved, I'll document the logic for others to hopefully learn from as well.

/etc/config/network

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

config globals 'globals'
        option ula_prefix 'fd1c:991c:6ab0::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'

config interface 'lan'
        option device 'br-lan'
#       option proto 'static'
        option ipaddr '192.168.10.1'            # not relevant in dhcp setting
        option netmask '255.255.255.0'          # not relevant in dhcp setting
        option gatway '192.168.10.1'            # not relevant in dhcp setting
        option ip6assign '60'
        option proto 'dhcp'

config interface 'vpn'
        option proto 'wireguard'
        option private_key '_REMOVED_'
        list addresses '198.19.3.134/16'

config wireguard_vpn 'wgserver'
        option public_key '_REMOVED_'
        option endpoint_host '_REMOVED_'
        option endpoint_port '_REMOVED_'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '0.0.0.0/0'
        list allowed_ips '::/0'

/etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/soc/fe300000.mmcnr/mmc_host/mmc1/mmc1:0001/mmc1:0001:1'
        option hwmode '11g'
        option channel 'auto'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'TESTssid'
        option encryption 'psk2'
        option key '_REMOVED_'

/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.d/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option ednspacket_max '1232'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option ra 'server'
        option ra_slaac '1'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'

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'
        option loglevel '4'

/etc/config/firewall

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

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

config zone 'wan'
        option name 'wan'
        list network 'lan'
        list network 'vpn'
        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 'fc00::/6'
        option dest_ip 'fc00::/6'
        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 rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config rule
        option name 'Support-UDP-Traceroute'
        option src 'wan'
        option dest_port '33434:33689'
        option proto 'udp'
        option family 'ipv4'
        option target 'REJECT'
        option enabled 'false'

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

Change these sections as follows in your /etc/config/network file (remove eth0 from br-lan, change lan interface to static IP*:

config device
        option name 'br-lan'
        option type 'bridge'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.10.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

*it is critical that the LAN subnet does not overlap with the upstream network.

Then add the following (in /etc/config/network):

config interface 'wan'
        option device 'eth0'
        option proto 'dhcp'

In the /etc/config/firewall file, fix the following:

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

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

Optionally, you could create a unique firewall zone for the VPN... this allows you to make a "kill switch" to prevent internet access except via the VPN. If you want to do that, it would look like this:

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

config zone 'vpn'
        list network 'vpn'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config forwarding
        option src 'lan'
        option dest 'vpn'

Regarding the "kill switch" option I mentioned above, you can remove this if you want to prevent internet access if the tunnel is down (assuming the VPN is on its own zone as described immediately above).

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

That absolutely worked – thank you sir !!

So to answer my own musings from above, a ‘br-lan’ (or simply lan) does NOT need to be associated with a physical port (ie. eth0) per se – that was the part that really confused me (the ‘br-lan’ device is akin to an internal virtual port I guess or the actual inner “bridge” and selecting it for the ‘br-lan’ does the trick).

The required steps were,

  1. A ‘wan’ needed to be created as a “dhcp client” and be associated with the physical port (eth0) for it to capture the upstream router/modem IP assignment
  2. The ‘br-lan’ (or simply lan) is set as a static IP address (as long as it falls outside of the upstream range) with dhcp enabled for it to generate IPs (where is that dhcp enabling taking place ? or is it being enabled by default on static IPs ?).

The “kill switch” doesn’t seem to work for whatever reason; I’m unable to reach the internet with the change. Below is the resulting firewall file with the “kill switch” just to make sure.

Thanks again for all your help @psherman

/etc/config/firewall

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

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

config zone 'wan'
        option name 'wan'
        list network 'wan'
#       list network 'vpn'              # Remove if "kill switch" below is used
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

# kill switch below - if no VPN, no wan
config zone 'vpn'
        list network 'vpn'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config forwarding
        option src 'lan'
        option dest 'vpn'

# Comment below section if "kill switch" is used
#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 'fc00::/6'
        option dest_ip 'fc00::/6'
        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 rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config rule
        option name 'Support-UDP-Traceroute'
        option src 'wan'
        option dest_port '33434:33689'
        option proto 'udp'
        option family 'ipv4'
        option target 'REJECT'
        option enabled 'false'

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

Correct. You can think of a bridge as a way of combining multiple logical devices into one contiguous network. So for example, multiple radios and/or ethernet devices.

That's the point of the kill switch. If you want to prevent internet access when the VPN is down for any reason, the forwarding rule from lan > wan needs to be removed (or commented) as is shown in your config. So it would appear that it is doing exactly what it should, unless I have misunderstood your description of the issue.

Three (3) inquires all related to this topic,

  1. Asked above - in relation to the "bridge"
  1. The "kill switch" is NOT working as I'm NOT able to get any outside connectivity; the vpn in "normal" instances works fine so not sure what's going on here. If I remove the "kill switch" firewall rules everything is back to normal and all traffic gets routed via the vpn. Can you take another look over that "kill switch" configuration to see why traffic is not making out to wan please. My understanding is that no lan traffic will go out until a vpn connection is established, but why isn't any traffic leaving once that vpn connection is made is the question.
  2. Now this is a bit of a curve ball - let's assume I mangle my WiFi/AP/Wireless settings by mistake (or forget the AP password) and am no longer able to login to the wireless or access it. How do I get back into the RPi (command line or LuCI) ? I tried to do this by hand (again to learn) and installed "OpenDHCPserver" on my windows 10, was able to assign an IP (192.168.0.100) to the RPi wan port but wasn't able to see LuCI or get an ssh prompt (which ought to be on 192.168.10.1). I suspect cause I don't have a route from wan->lan and thus my question - is there a relatively safe way to enable emergency wan->lan access without opening myself to outsider attacks or external probes ?

There is a DHCP server (dnsmasq) as configured in the /etc/config/dhcp file. The relevant section for your LAN is here:

It is possible to disable the DHCP server (entirely or on a per-interface basis), but you almost certainly want it to be enabled on the LAN created by your Pi.

The point of the kill switch is to prevent traffic from being routed from the LAN > WAN when the VPN is not active. When the VPN is active, you should have internet connectivity from the LAN.

The kill switch method is to actually remove/deactivate the lan > wan forwarding rule.

This is by design. If the lan > wan forwarding rule is removed or disabled, it means that there will be no ability for traffic to flow from the LAN > WAN. I know that works in general, and I'm 99% certain that it is working as expected in your case. Maybe you are expecting that you add / enable a rule to block the lan from the internet? Could that be the cause of the confusion?

The vpn network must be removed from the wan zone -- it should not be part of the wan zone at all, ever. You have assigned the vpn network to the vpn zone, and the network should only be part of a single zone. Because the vpn network was associated with the wan zone, it would explain the behavior you are seeing.

The wan zone should look like this:

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

You have a few options:

  • pop the SD card out of the Pi and put it into a computer. As long as your computer can read the file system on the card, you can actually go in and edit the file (i.e. /etc/config/wireless).
  • connect a keyboard and a display to the Pi. You'll be able to access the command line interface via the console.
  • failsafe mode, although I don't know if the Pi has a way to enter failsafe mode since it doesn't have a button to press... maybe via the GPIO pins?

This didn't work for several reasons. First, OpenWrt by default, does not allow connections originating from the upstream network (i.e. the wan). It is possible to allow those connections, but it is a very bad idea from a security standpoint unless the upstream network will always be a trusted one (i.e. behind a firewall that you trust and with users/devices that you own and control or have reasonable knowledge about their trustworthiness). If this device will ever be connected directly to the internet or maybe to a hotel network or whatever, you do not want to expose the router's admin features to an untrusted network. There is a secondary reason that it didn't work -- the address 192.168.10.1 is from the Pi's address from the perspective of the LAN it creates. However, on the wan side (i.e. your win10 system with the DHCP server running), the hosts on that network (i.e. win10 machine) has no knowledge of where to find 192.168.10.1 -- it only knows that it can find 192.168.0.100 -- the wan address of the Pi. You can think of it like calling a business -- you could have the external number for that business and maybe you press 2 to get to a specific department, but you don't have knowledge of how they have setup their internal phone system, and you don't have the ability to enter in the specific extension for an individual person. Conversely, if I said: call "52341," and you didn't know the external phone number, you'd have no way to make the call. Maybe not a perfect analogy, but hopefully it makes sense.

Not really. I mean, I can think of some ways it could be done, but I wouldn't recommend it because it cannot be guaranteed to be secure in all circumstances. After all, if you can get in, someone else can try (it's kind of the backdoor/universal encryption key argument -- maybe you can actually trust a specific government to use it responsibly, but all it takes is for one bad actor (individual or a nation/state) and all systems using that encryption technology would immediately be vulnerable).

Regarding the "kill switch" config,

I'm fully aligned, what I was expecting with this "kill switch" config is that when I turn-on the RPi, it would establish a vpn tunnel and would NOT allow any traffic through until that tunnel is fully functional. If the vpn tunnel goes down, for whatever reason, then all the LAN traffic would not be allowed to pass through to the WAN - is that not what is expected ? But what is happening now is that if I include the "kill switch" config, the RPi never allows anything through, its as though the vpn tunnel doesn't get established.

Agreed and it already does with the "kill switch" config (note commented out 'vpn' line)

You're right, I was over-complicating things I guess :smile:

@psherman, are my expectations below misplaced/wrong ?

Your expectation is correct. Let's take another look at the latest /etc/config/firewall file with the "kill switch" enabled.

I got it working and confirmed that if the VPN doesn't come-up (I changed one of the keys on purpose for it to simply not establish and it worked as expected) by adding an extra line below (see "New Addition"). @psherman, I'm good to go unless you see anything that looks out of the ordinary or if the new line that I added shouldn't be there.

Thanks Again !!

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

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

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

# kill switch below - if no VPN, no routing/traffic
config zone 'vpn'
        option name 'vpn'               # New Addition
        list network 'vpn'
        list network 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config forwarding
        option src 'lan'
        option dest 'vpn'

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 'fc00::/6'
        option dest_ip 'fc00::/6'
        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 rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config rule
        option name 'Support-UDP-Traceroute'
        option src 'wan'
        option dest_port '33434:33689'
        option proto 'udp'
        option family 'ipv4'
        option target 'REJECT'
        option enabled 'false'

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

Remove the wan network from this zone.

Cool, I'm all set - thanks a million @psherman for all your help !!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.