It works perfectly for PPTP VPN, however there is one thing that I can’t get to work- when the VPN is active, I no longer can connect to my NAT routes, ie http://www.company.com no longer forwards to 192.168.1.23 and back out. I can see the packets increasing on the NAT route however.
I imagine it possibly has to do with the packet mark or routing from one input interface and out another… however for the life of me I can’t figure it out!
Would really appreciate a tip (or 2 or 3). Thank you so much for your consideration!
Hi, I thought I would post some information on my configuration. Here is my route information
/ip route> print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 PIA - US-Califo... 1
1 X S 0.0.0.0/0 PIA - AU-Melbourne 2
2 X S 0.0.0.0/0 PIA - AU-Adelaide 3
3 ADS 0.0.0.0/0 180...120 1
4 ADC 10.1.1.1/32 10.1.1.10 PIA - AU-Melbourne 0
PIA - AU-Adelaide
PIA - US-Califo...
5 ADC 180.148.65.120/32 180...219 pppoe-out1 0
6 ADC 192.168.1.0/24 192.168.1.254 bridge1 0
7 ADC 192.168.2.0/24 192.168.2.253 ether1 0
I am experiencing exactly the same issue on my CRS125 with PIA using L2TP/IPSEC. I have used this tutorial https://www.youtube.com/watch?v=aIUTfiGkmzk to set everything up.
I have tried the suggestion to add my public IP to a new address list. But that didnt work unfortunately.
2015-04-02_2338.png
Alex
So let’s make sure I understand this - the pinholes break when the VPN is up…
Fair enough. I read your rules, and basically, if a connection comes in on a pinhole, the replies are being forced out the VPN if it’s active, so ultimately the reply gets to the remote party, but alas, from god knows what public IP…
To fix this:
Mark connections (not packets) that come in on pppoe1 with a mark, and instruct route marking rule to ignore these connections.
How to impliment the fix:
Add another condition to your existing mangle rule: connection-mark=!novpn
Then add a second rule to prerouting, before the existing one:
add action=mark-connection chain=prerouting connection-state=new new-connection-mark=novpn passthrough=no in-interface=pppoe-out1
You don’t need any rule to do route marking on individual packets for the connection ‘novpn’ because you’re only using one route mark, so making it ignore packets in ‘novpn’ will allow the pinhole traffic to use the regular routing table.
That works great for external traffic to internal servers, however my my hairpin NAT still fails, however I have found a fix - telling it also to ignore traffic that is classed as “local”. So here are my rules:
That, or else add the LAN network to the vpn routing table. Either is good - and I think in this case, the “ignore for hairpin traffic” method is more consistent with the rest of the rules, so it’s probably the better solution. (readability is good)
For my own curiosity, would you explain that “add the lan network to vpn routing table” - I think that it might better assist me in understanding overall this whole process (I am still coming to terms with Mangle completely).
Sure - when you have a packet with a routing mark, it will only match routes in the routing table with the same route mark.
Whenever you put an IP address on an interface, the appropriate route appears in the routing table with no routing mark, and the flags ADC - “active, dynamic, connected” and a distance of 0. This is standard for pretty much any router.
The problem is that if you mark a packet with a routing mark, this locally-connected network will not be in the routing table anymore - at least not for packets with some routing mark on them.
Adding a second copy of the route as a manual static route, and with the routing mark, will make the local network appear in the routing table again for these route-marked packets. These manual routes will just be flagged “AS” - active, static, but that doesn’t matter to the packets.
So before manually adding the LAN network to the VPN routing table (all routes with a routing mark, collectively make a whole new routing table), if you skip the marking rule, packets will reach that network using the main routing table. If you mark the packets, but don’;t have the destination in the routing table, they won’t go the right way - they’ll follow the default gw, for instance… not what you want. So adding LAN to the vpn table as well is another way to let these vpn packets see the LAN network and route properly.
Thanks for your work in this thread. I managed to get the NAT rules and my Private Internet VPn setup. However I have been noticing that some sites have been responsive and others simply wont reply any more. I have read online and on this forum to see what this could be. What would be a good way to bugfix this issue?
But in regards to the sites not working, I have also found this. I initially thought it might be MTU related, however I think that because many hits go to some sites with the same IP, the site might block the traffic thinking it is spam, or the IP is on a blacklist. I have change my VPN to the au melbourne one and cleared out the Mikrotik DNS cache and the browser cache and now most sites are working.
YMMV however PIA has been a little disappointing in this regard. I guess you can’t get privacy without the added bonus of some people using the service nefariously. I might be wrong though. Please let me know
Thanks for your rule suggestion, it does seem to work when I enable my address list rule back for my device. However sites like adobe.com and a Dutch one at5.nl still wont work. I will try and test with another PIA country configured. Also see if it makes a difference if I use the PIA application directly on my PC.
What are your MTU settings by the way? I have also read that this might affect VPN performance.
I faced a similar problem but what I could understand is that my VPN was not configured correctly. What I initially gauge is that my VPN service didn’t support NAT but after digging deep, I changed some mangle rules and it started working. I too used PIA and referred to their customer support in sorting this issue. Considering their fast and responsive customer support, NAT is now successfully working with the VPN and also read the detail private internet access review for better understanding about its feature and services.
