Question: openVPN "redirect all traffic" configuration


can anyone who has configured OpenVPN through Foris allowing redirection of all traffic through the VPN post their configuration (including firewall)? I have some issues I traced back to the firewall but I need an example of working configuration to check where I did wrong.

Is that OpenVPN client or OpenVPN server you are asking about?

The OpenVPN server, but not only the openVPN configuration, also the firewall configuration created by Foris. The latter is what interests me most.

Can you establish any connection to the server or is just the redirect of all traffic not working?

I have these vpn related config in my /etc/config/firewall:

#allow input to openvpn daemon (start the tunnel)
config rule 'Allow_OpenVPN_Inbound'
        option target 'ACCEPT'
        option src '*'
        option proto 'udp'
        option dest_port '1194'

# allow traffic towards and from the tunnel network
config zone 'vpn_turris'
        option name 'vpn_turris'
        option input 'ACCEPT'
        option forward 'REJECT'
        option output 'ACCEPT'
        option masq '1'
        option network 'vpn_turris'

# forward traffic to other interfaces
config forwarding 'vpn_turris_forward_lan_in'
        option src 'vpn_turris'
        option dest 'lan'

config forwarding 'vpn_turris_forward_lan_out'
        option src 'lan'
        option dest 'vpn_turris'

config forwarding 'vpn_turris_forward_wan_out'
        option src 'vpn_turris'
        option dest 'wan'


config openvpn 'server_turris'
        option enabled '1'
        option port '1194'
        option proto 'udp'
        option dev 'tun_turris'
        option ca '/etc/ssl/ca/openvpn/ca.crt'
        option crl_verify '/etc/ssl/ca/openvpn/ca.crl'
        option cert '/etc/ssl/ca/openvpn/01.crt'
        option key '/etc/ssl/ca/openvpn/01.key'
        option dh '/etc/dhparam/dh-default.pem'
        option server 'x.x.x.x'
        option ifconfig_pool_persist '/tmp/ipp.txt'
        option duplicate_cn '0'
        option keepalive '10 120'
        option comp_lzo 'yes'
        option persist_key '1'
        option persist_tun '1'
        option status '/tmp/openvpn-status.log'
        option verb '3'
        option mute '20'
        list push 'route y.y.y.y'
#this triggers the redirect of all traffic on the client
        list push 'redirect-gateway def1'
        list push 'dhcp-option DNS z.z.z.z'
        option client_to_client '1'
        option mode 'server'
#following only if you want ipv6 inside the tunnel (still experimenting with this one)
        option server_ipv6 'aaaa:bbbb:cccc:d::/64'
        option tun_ipv6 '1'
        list push 'route-ipv6 aaaa:bbbb:cccc:e::/64'
#trigger redirect of all public ipv6 traffic
        list push 'route-ipv6 2000::/3'
        list push 'redirect-gateway ipv6'
        list push 'tun_ipv6'

Also if you want to establish the connection over a public ipv6 address you have to (create a copy of the config and) change option proto 'udp' to option proto 'udp6'

It was simply a misconfigured push DNS option and a missing forwarding from VPN to WAN. The DNS pushed need to be in the same subnet as the VPN (easy, because it’s the same), so I just used the VPN IP of the VPN server. If I put the internal network IP for the DNS, it would refuse queries and reply with UDP port unreachable (seen with tcpdump).

Small addition: it is not required to have the dns server in the same subnet. The server just needs to be reachable over the tunnel (allow forwarding) or from the clients remote location via the internet (eg. google dns)

That would be true, but I meant that I’m using knot on the Omnia without forwarding to handle DNS and that won’t work unless the request is from the same subnet due to a source IP mismatch. Test with another VPN that has the same issue (the address is from the internal LAN, the other is the VPN):

;; reply from unexpected source:, expected
;; reply from unexpected source:, expected
;; connection timed out; no servers could be reached