OpenVPN config with IPv6

Kherby · September 3, 2018, 10:07pm

The VPN connection is working now but i do have some problems with IPv6.
Solution was to change proto UDP to TCP...

My current working OpenVPN config:

config openvpn 'myvpn'
        option dev 'tun'
        option ca '/etc/openvpn/ca.crt'
        option cert '/etc/openvpn/client.crt'
        option key '/etc/openvpn/client.key'
        option client '1'
        option remote_cert_tls 'server'
        option auth_user_pass '/etc/openvpn/userpass.txt'
        option persist_tun '1'
        option persist_key '1'
        option auth 'SHA256'
        option cipher 'AES-256-CBC'
        option verb '4'
        option disable_occ '1'
        option port '443'
        list remote 'SERVERNAME'
        option comp_lzo 'adaptive'
        option remote_random '1'
        option enabled '1'
        option proto 'tcp-client'
        option tun_ipv6 '1'
        option route_nopull '1'

Kherby · September 3, 2018, 5:16pm

I think that i have fixed the problem by changing the proto to TCP. But i also added/changed a few other options so i can't tell for sure that it was only related to UDP. For example i activated the pull Option (Accept options pushed from server) under my OpenVPN settings.
I'm still very confused...

Current config:

config openvpn 'myvpn'
        option dev 'tun'
        option ca '/etc/openvpn/ca.crt'
        option cert '/etc/openvpn/client.crt'
        option key '/etc/openvpn/client.key'
        option client '1'
        option remote_cert_tls 'server'
        option auth_user_pass '/etc/openvpn/userpass.txt'
        option persist_tun '1'
        option persist_key '1'
        option auth 'SHA256'
        option cipher 'AES-256-CBC'
        option verb '4'
        option disable_occ '1'
        option port '443'
        list remote 'SERVER NAME'
        option comp_lzo 'adaptive'
        option pull '1'
        option remote_random '1'
        option enabled '1'
        option proto 'tcp-client'

Maybe the server just don't like UDP.

Since it's working now i do have another question regarding IPv6 and VPN. At the moment my ISP IPv6 address doesn't seem to leak when connected over the VPN but i wonder if there is a way to ensure that it will never happen...? Another thing that confuses me is that the dns resolution of a ipv6 address is working but i do get timeouts after the first hop (router).
As far as i know my VPN Provider does support IPv6 and ifconfig shows a valid (/112) IPv6 address for the tun0 interface but i'm not able to surf any ipv6 website when connected over VPN.
There are also a few sys log message regarding IPv6: e.g.

daemon.notice openvpn(myvpn)[5822]: /sbin/route -A inet6 add 2000::/3 dev tun0
daemon.notice openvpn(myvpn)[5822]: add_route_ipv6(2000::/3 -> 2a00:xxx::xxx:xxx:204:0:1 metric -1) dev tun0
daemon.notice openvpn(myvpn)[5822]: Initialization Sequence Completed

Does anyone know if there is any special configuration needed to use IPv6 with my VPN provider?

What i did so far:

1. enabled "Use builtin IPv6-management"  for my VPN Interface.
2. tun_ipv6 is checkd in my OpenVPN config

The service status under VPN policy-routing shows the IPv4 VPN server address but only ::2000 at the end, so no valid IPv6 address if i get it right.

Sorry for so many questions but i'm realy noobish when it comes down to IPv6 and VPN.

Best regards, Kherby

iplaywithtoys · September 3, 2018, 5:21pm

Some ideas off the top of my head...

Test each component in sequence. The problem could be with your provider, or it could be with your router, or it could be with your clients behind your router.

Install tcpdump on the router. You'll need it to observe outgoing traffic as well as incoming traffic, on a per-interface basis. If you can see incoming traffic on the LAN interface, but can't see corresponding outgoing traffic on the VPN interface, then your router's not, er, routing.

From the router, test if you can ping a public internet address after establishing the VPN. Google and Cloudflare's DNS servers (8.8.8.8, 8.8.4.4, 1.1.1.1, 1.0.0.1) are good targets.

Then test if you can traceroute from the router to the same address. Observe the path taken. Does it go through your VPN provider or not?

Check your clients. What is their gateway address? Can you see traffic from the clients reaching interface eth0.1? Can you see matching traffic leaving the router on interface vtun0? Or can you see matching traffic leaving the router on interface eth1.2?

iplaywithtoys · September 3, 2018, 5:27pm

Ah. Our replies crossed.

If the VPN server is unable to tell the client to send (route) traffic through the VPN, then the traffic won't go where expected. Allowing the server to push a configuration to the client is how the server tells the client, "Send your traffic through me."

iplaywithtoys · September 3, 2018, 5:30pm

As for IPv6, your firewall configuration doesn't have any IPv6 rules in it. The factory default configuration ships with some IPv6 rules already installed. Do you need to create some IPv6-specific rules?

Kherby · September 3, 2018, 5:43pm

I've unchecked "route_nopull" in my openvpn config again and my VPN connection is still working thanks to the vpn-policy-routing package.
But my ISP IPv6 is leaking now and that is pretty much unwanted bevaviour if i connect over VPN.

So now i have to find out how to use the IPv6 address of my VPN provider instead of my ISP address when i'm connected over VPN or how to disable the use of any IPv6 address when connected over the VPN.
I thought this will be a bit easier...

All the default rules sill active and i've just disabled the Allow-Ping rule for IPv4...
To be honest i'm not sure which rule i would need to add to allow (or better say force) the use of the IPv6 address of my VPN provider when i'm connected over VPN.

Here is a list of all my traffic rules:

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'
	option enabled '0'

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 target 'ACCEPT'
	option proto 'tcp udp'
	option dest_port '53'
	option src 'guest'
	option name 'DNS [Guest]'

config rule
	option target 'ACCEPT'
	option proto 'udp'
	option dest_port '67-68'
	option src 'guest'
	option name 'DHCP [Guest]'

config rule
	option proto 'tcp udp'
	option dest_port '80 443'
	option name 'Deny Router Access [Guest]'
	option src 'guest'
	option target 'REJECT'

config rule
	option dest_port '22'
	option name 'Deny SSH Access [Guest]'
	option src 'guest'
	option target 'REJECT'
	option proto 'tcp udp'

config rule
	option name 'Deny Modem Access [Guest]'
	option proto 'all'
	option src 'guest'
	option dest_ip '192.168.252.0/24'
	option target 'REJECT'
	option dest '*'

Thanks for your time!

iplaywithtoys · September 3, 2018, 6:12pm

I've not played with IPv6 over OpenVPN with OpenWRT, so this is just guesswork. However, I notice that the source for all those IPv6 rules is "wan". Could that be relevant?

Kherby · September 3, 2018, 7:03pm

Could be relevant but im also not a expert when it comes down to IPv6 and the firewall rules for it.
I wasn't very successfull with google about that problem so i'm still hoping that someone can shed some light about this...

edit: Another Problem... I do loose access to my Modem when the VPN connection is up but i think that's related to vpn-policy-routing because when i stop the service i can access my modem again.

iplaywithtoys · September 3, 2018, 7:20pm

That makes sense. If the VPN is configured to route all traffic, then the VPN would intercept traffic for your modem before it reaches your modem.

The other way to configure it is for a "split tunnel", which sends some traffic through the VPN and some out the normal route.

Kherby · September 3, 2018, 7:25pm

The weird thing is it also happens if i select the WAN as the policy and my modem is part of the WAN firewall zone.
I only run into problems with this VPN service on my router... The thing is i had another VPN running in the past with an older Version of LEDE (i think it was 17.01.4) and eveything was working fine but i dont remember how i got it done in the end.
Pretty frustrating at the moment. One thing working > Next thing broke.

iplaywithtoys · September 3, 2018, 7:33pm

There are two components which must both work, for traffic to flow:

The routing table
The firewall / packet filter

The first one tells the traffic where to go.
The second one tells the traffic whether or not it's allowed to go.

If your routing table is fine but your firewall isn't, your router can know exactly where to send the traffic but be denied. Alternately, if your firewall is fine but your routing table is wrong, your router may be permitted to send traffic but not have any idea where to send it.

The VPN alters the routing table (where to send the traffic). If the routing table never sends the traffic to the WAN zone, then that bit of the firewall will never know about the traffic to permit or deny it.

Kherby · September 3, 2018, 7:53pm

Sounds legit but i have no idea how to fix this behaviour...

Here is my current routing table (my modems ip is 192.168.252.254:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         ISP-GATEWAY  0.0.0.0         UG    0      0        0 pppoe-wan
VPN-SERVER    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
ISP-GATEWAY   0.0.0.0         255.255.255.255 UH    0      0        0 pppoe-wan
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
192.168.55.0    0.0.0.0         255.255.255.0   U     0      0        0 br-guest
192.168.252.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1.2

And here are the advanced options of vpn-policy-routing:
policy_advanced

Do you have any idea how i can fix this? I'm a bit lost...

iplaywithtoys · September 3, 2018, 8:00pm

Not immediately, but one troubleshooting suggestion I can make is to strip it back to basics. Get OpenVPN working in its default configuration, without any extras such as PBR. Then gradually add extras such as PBR until something breaks. Then look at the last thing you added.

I've not played with the particular PBR package you mention so I can't offer specific suggestions for that package. I'll be able to set up an OpenWRT VPN client with that PBR package to test, but probably not tonight; it may have to wait until tomorrow or Wednesday.

Kherby · September 3, 2018, 8:07pm

I'll reset my router in a few minutes, configure everything from the scratch and let you know how it went.
The thing is i do need something like PBR because i dont want some clients on my network to use the VPN connection...

Thanks again for your time and for trying to help me. I much appreciate it!

Kherby · September 3, 2018, 9:59pm

@iplaywithtoys
I found the solution for my modem problem in the discussion thread of VPN PBR. I was kinda blind when i searched for a solution...

Here is my working config for PBR:

config vpn-policy-routing 'config'
	option verbosity '2'
	option dnsmasq_enabled '1'
	list supported_interface 'modem'
	option ipv6_enabled '0'
	option strict_enforcement '0'
	option enabled '1'

config policy
	option name 'MODEM_ACCESS'
	option local_addresses '192.168.1.0/24'
	option remote_addresses '192.168.252.254'
	option interface 'modem'

config policy
	option name 'VPN_TEST'
	option local_addresses '192.168.1.230/32'
	option interface 'vpn0'

I'm now also able to access my modem with PBR + policies active!
Now i'm trying to fix the IPv6 problem but i haven't made any progress so far...

buckaroo · September 4, 2018, 3:15am

I don't think ipv6 vpn will work well in any case. AFAIK, no commercial vpn provider gives a routable /64 block, which is what you'd need for the router to assign ipv6 ips to clients. Short of that, you'll have to set up some sort of ipv6 NAT, which I don't know if anyone has really documented.

Kherby · September 4, 2018, 9:54am

I dont know much about VPN+IPv6 but here is what my current VPN provider is writting about IPv6:

I'm still seeing my ISP IPv6 address when doing a ip check with IPv6 enabled, when connected over the VPN...

buckaroo · September 4, 2018, 10:20am

That is scant on details, but all vpns that support ipv6 generally only do so if the client (laptop,phone etc.) is connected to the vpn because they give a single ipv6 address. When you put a router in between, it becomes more complicated, and won't work out of the box. ipv6 NAT is probably not widely recommended/documented, but you can try some stuff based on this: https://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/ch18s04.html. The other alternative is to setup a vpn server where you have a larger ipv6 space, and you can do it the right way. That is generally more expensive than paying for a vpn.

Edit: If you just want to block your ISP's ipv6, that is a simpler problem to solve that getting ipv6 to work with your vpn

Kherby · September 4, 2018, 10:47am

That would be totally fine for me!

So when i'm connected over VPN (configured via VPN Policy Based Routing) IPv6 should be disabled (for the configured IP address) and no IPv6 leaks should occour.
But if a device on the same network is using the WAN connection (default without policy) IPv6 should be working.
With my current OpenVPN and VPN PBR config any device or IP range that isn't configured will go through the WAN interface and that is totaly fine as i dont want every device to use the VPN connection 24/7.
And i dont know how i would be able to block IPv6 traffic when i use the VPN connection while staying on the same Network with IPv6 assignment turned on (so other devices on the same network are able to use IPv6 over my normal ISP/WAN connection).

It realy doesn't seem to be that easy when IPv6 comes into play...

buckaroo · September 4, 2018, 11:19am

The easy solution could be to just disable ipv6 on the clients that you want to do selective routing with.