Posted: Tue May 11, 2021 11:48 Post subject: [SOLVED]VPN and ipset
Hi everyone,
After some long hard work I managed to set up ipset. Now I want to use these ipset tables to have 'normal' traffic to use the vpn (which is working already) and some traffic (ipset) to bypass the vpn (netflix, youtube and Office 365 for now).
Although I have read many different topics about vpn, ipset, pbr, I just want to verify if what I intend doing would get this working.
I have Ipset save on exit and restore on restart of the router by the way.
This is the script (that I would have to save as a firewall script?) that i came up with after reading some documents by forum member egc:
#add default route to alternate table
ip route add default via 192.168.0.1 table 100
#add local routes to alternate table
ip route add 127.0.0.0/8 table 100
ip route add 192.168.0.0/23 table 100
ip route add 192.168.10.0/23 table 100
# force routing system to recognize our changes
ip route flush cache
# add firewall rule
iptables -t mangle -D PREROUTING -m set --match-set NETFLIX dst -j MARK --set-mark 40
iptables -t mangle -A PREROUTING -m set --match-set NETFLIX dst -j MARK --set-mark 40
iptables -t mangle -D PREROUTING -m set --match-set OUTLOOK.OFFICE365 dst -j MARK --set-mark 40
iptables -t mangle -A PREROUTING -m set --match-set OUTLOOK.OFFICE365 dst -j MARK --set-mark 40
iptables -t mangle -D PREROUTING -m set --match-set OUTLOOK.OFFICE dst -j MARK --set-mark 40
iptables -t mangle -A PREROUTING -m set --match-set OUTLOOK.OFFICE dst -j MARK --set-mark 40
iptables -t mangle -D PREROUTING -m set --match-set YOUTUBE dst -j MARK --set-mark 40
iptables -t mangle -A PREROUTING -m set --match-set YOUTUBE dst -j MARK --set-mark 40
# start split tunnel
ip rule del fwmark 40 table 100
ip rule add fwmark 40 table 100
Joined: 18 Mar 2014 Posts: 12904 Location: Netherlands
Posted: Tue May 11, 2021 16:30 Post subject:
You probably also found the route scripts which are accompanying the IPSET documentation
Although I made an example for WireGuard it also should work for OpenVPN, so yes basically this is how you make an alternate routing table and reroute FireWall Mark traffic via that alternate routing table
So have a go and let us know if it works
P.S. also have a look at @eibgrads excellent (IPSET)-script which is designed for use with OpenVPN:
https://pastebin.com/nC27ETsp
P.P.S. It is always helpful if you state router model and build number.
To get the best out of DDWRT and the forum read the forum guidelines with helpful pointers:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
If you have not already read the forum guidelines, please do !!
EDIT:
Code:
ip route add 192.168.0.0/23 table 100
ip route add 192.168.10.0/23 table 100
You probably also found the route scripts which are accompanying the IPSET documentation Smile
Sure did!
Already found some stuff by @eibgrad, but those scripts were a bit to lengthy for me. To get a grip on what's happening I want to understand what happens for what reason; so rather a few lines of 'code'. Nature of the beast I suppose
Quote:
Code:
ip route add 192.168.0.0/23 table 100
ip route add 192.168.10.0/23 table 100
Yes, this is intentional. I have a subnet that hosts some reserved addresses (...10.xxx) and a subnet for dhcp leases (...11.xxx). The latter I use for all devices (kids off course) that I prohibit from using internet at a time schedule. Had to work around the 'private address' feature (Apple in this case), that's why.
My router is a Linksys WRT3200ACM and it's running on DD-WRT v3.0-r44715.
I will try to apply the script in a couple of hours.
One more question; I am using NextDNS at the moment, works like a charm for blocklists and all that. Using these in the vpn would be no more than adding server=xxx.xxx.xxx.xxx to Additional Dnsmasq Options right?
Does this have to added as well in that case (without the hashes)?
Joined: 18 Mar 2014 Posts: 12904 Location: Netherlands
Posted: Wed May 12, 2021 8:03 Post subject:
You make one alternate routing table (table 100)
This table has a default route via the WAN.
so all traffic using this table will use the WAN.
Your main table (which has actually number 254) uses the VPN.
You can "associate" traffic to use this table 100 in various ways.
The IPSETs uses a firewall mark, you tag IPSET traffic with fwmark 40 (that is the PREROUTING rule)
Next thing is that you associate fwmark 40 with table 100 with "iprule add fwmark 40 table 100"
Now all IPSET traffic will use table 100 and thus the WAN and not the default table which uses the VPN.
You can also associate source addresses, destination addresses, source and destination port etc.
So if you want your IPTV which has address 192.168.1.64 with table 100 you do:
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Wed May 12, 2021 14:58 Post subject:
djuroutski wrote:
How do I verify if the ipset traffic really bypasses the vpn?
Set up a pair of firewall rules with -s on the ipset but with no -j action at the end. Give one rule "-o tun1" (or whatever your vpn tunnel interface is) and the other "-o eth0" (or whatever your WAN interface is). Then you can check the packet counts on those two rules when you want to see where stuff has been going. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Works like a charm! At first forgot to change the firewall scripted, but in the end found out that part was missing. Then was able to verify that everything is working like i think it should!
I had some errors in the logging regarding the MTU sizes.
Now I have configured (as it appears to be impossible to directly configure link-mtu) tun-mtu in a way that the error for the link-mtu has been resolved.
However: what's the best way to go abou this? Adjust the tun-mtu to the value that logging reports for the remote value for tun-mtu or the way I did as described above?
Joined: 18 Mar 2014 Posts: 12904 Location: Netherlands
Posted: Tue May 18, 2021 12:37 Post subject:
mtu is really a can of worms.
You can set it according to the log (the server side) but only if it is lower than 1500 (usually it is not), The warning will go away but it is not a real solution.
At this moment we default to 1400 to be on the safe side.
For my own setup I manually searched for the optimal mtu which was 1448 usually it is lower (depends on wan-mtu used cipher/compression etc.)