Followed this tutorial to get my SurfShark IPSec VPN handling all outbound traffic, but want my outbound SSL VPN traffic for work to go straight out my ISP.
I've read a bunch of bypass VPN for Netflix and such articles and came up with...
Added a new default route with a routing-Mark and a Mangle based on destination IP and/or destination port with a new-routing-mark, but everything still going to SurfShark.
Now I am just trying to get all HTTP & HTTPS traffic to bypass SurfShark since it is easiest to test and can't even make that work. All the traffic is hitting the Mangle, but still going in the tunnel!!!???!!!??? Any help appreciated.
/ip route
add distance=1 gateway=96.38.160.1 routing-mark=BypassVPN
/ip firewall mangle
add action=mark-routing chain=prerouting dst-port=80,443 new-routing-mark=\
BypassVPN passthrough=no protocol=tcp src-address=10.236.1.0/24
Other relevant config...
/ip firewall address-list
add address=10.236.1.0/24 list=local4VPN
/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN
/ip ipsec mode-config
add name=USSFO responder=no src-address-list=local4VPN
/ip ipsec policy group
add name=USSFO
/ip ipsec profile
add name=USSFO
/ip ipsec peer
add address=us-sfo.prod.surfshark.com exchange-mode=ike2 name=USSFO profile=\
USSFO
/ip ipsec proposal
add name=USSFO pfs-group=none
/ip ipsec identity
add auth-method=eap certificate=surfshark_ikev2.crt_0 eap-methods=\
eap-mschapv2 generate-policy=port-strict mode-config=USSFO password=\
******************** peer=USSFO policy-template-group=USSFO username=\
********************/ip ipsec policy
add dst-address=0.0.0.0/0 group=USSFO proposal=USSFO src-address=0.0.0.0/0 \
template=yes
Re: allow SSL VPN to bypass IPSEC SurfShark tunnel
Appreciate the link, but it is exactly the opposite of the scenario I am describing.
I need a Use-case #4: Specific traffic (by destination and/or destination port preferably) routed AROUND VPN server
I'll see if I can tweek their use-case #2, but not really the same.
Re: allow SSL VPN to bypass IPSEC SurfShark tunnel
In step 16 of that tutorial, they set a src-address-list parameter on the mode-config row to local. This causes an action=src-nat rule to be dynamically added to the srcnat chain of /ip firewall nat, which matches on src-address-list=local whenever the IPsec connection established.
This rule is always placed to the very top of the chain, so you cannot place any other rule before it.
So to fulfil your goal, you have to let this rule match on a connection-mark value rather than on a src-address-list, and use rules in /ip firewall mangle to assign a connection-mark to traffic that should be sent via SurfShark, and some other connection-mark (or none at all) to traffic that should not.
So while the peer or identity is disabled, unset the src-address-list parameter on the mode-config row, and set the connection-mark one to e.g. via-surfshark. Then, add the following rules:
/ip firewall mangle
add chain=postrouting connection-mark=!no-mark action=accept passthrough=no
add chain=postrouting out-interface=your-sstp-interface-name action=mark-conection new-connection-mark=other passthrough=no
add chain=postrouting out-interface-list=WAN ...possibly some additional match conditions to restrict the choice of traffic... action=mark-conection new-connection-mark=via-surfshark passthrough=no
add chain=postrouting out-interface-list=WAN action=mark-connection new-connection-mark=other passthrough=no
The first rule will match on all packets belonging to already marked connections, i.e. 99.9 % of all packets will only hit this single rule.
The first outbound packet of each connection will get past that rule. One of the two following rules connection-marks it either with other if the regular routing has routed it via the SSTP tunnel, or with via-surfshark if the regular routing has sent it down the default route via WAN and the packet has met the additional match conditions eventually stated in that rule. If no additional conditions exist because everything that doesn't go via SSTP can go via SurfShark, the fourth rule is not necessary. Otherwise it must be there so that no connection would stay without any connection-mark value and thus each of its packets would have to pass through all the three rules.
All of these rules except the first one ignore traffic towards LAN, so the connection-mark is not assigned when handling initial packets of connections initiated from the internet side, for the case that any such connections would be needed.
This rule is always placed to the very top of the chain, so you cannot place any other rule before it.
So to fulfil your goal, you have to let this rule match on a connection-mark value rather than on a src-address-list, and use rules in /ip firewall mangle to assign a connection-mark to traffic that should be sent via SurfShark, and some other connection-mark (or none at all) to traffic that should not.
So while the peer or identity is disabled, unset the src-address-list parameter on the mode-config row, and set the connection-mark one to e.g. via-surfshark. Then, add the following rules:
/ip firewall mangle
add chain=postrouting connection-mark=!no-mark action=accept passthrough=no
add chain=postrouting out-interface=your-sstp-interface-name action=mark-conection new-connection-mark=other passthrough=no
add chain=postrouting out-interface-list=WAN ...possibly some additional match conditions to restrict the choice of traffic... action=mark-conection new-connection-mark=via-surfshark passthrough=no
add chain=postrouting out-interface-list=WAN action=mark-connection new-connection-mark=other passthrough=no
The first rule will match on all packets belonging to already marked connections, i.e. 99.9 % of all packets will only hit this single rule.
The first outbound packet of each connection will get past that rule. One of the two following rules connection-marks it either with other if the regular routing has routed it via the SSTP tunnel, or with via-surfshark if the regular routing has sent it down the default route via WAN and the packet has met the additional match conditions eventually stated in that rule. If no additional conditions exist because everything that doesn't go via SSTP can go via SurfShark, the fourth rule is not necessary. Otherwise it must be there so that no connection would stay without any connection-mark value and thus each of its packets would have to pass through all the three rules.
All of these rules except the first one ignore traffic towards LAN, so the connection-mark is not assigned when handling initial packets of connections initiated from the internet side, for the case that any such connections would be needed.