Hiding router address from VPN tunnels

[drdog]

I have created a PPPoE client to interface with my ISP - therefor my internet facing address is the one assigned to the PPPoE client by my ISPs DHCP server, lets say it is 45.67.89.123

The normal wireless AP [SSID PPP] connects to the 192.168.88.0/24 network on the LAN side of the router and is SRCNAT routed to my ISP via the PPPoE client and then on to the internet.

There is a router rule 0.0.0.0/0 gateway PPPoE1

I have also created a PPTP client to a VPNbook server.which creates me a second route out to the internet.
I have a virtual AP [SSID vpn) with a DHCP serve. Using a mangle rule I can mark packets from wpn_ap to go out via the PPTP client. This works for external addresses except for my PPPoE client address (my router’s WAN address)

So if I connect a device to the PPP ap and do a trace route to say 8.8.8.8, then I can see the route going via my ISP
If I connect the device to the VPN ap and do the same trace route I can see a completely different route going via the VPN server.

Assuming my ISP has a pool of addresses eg 45.67.89.0/24 then, while connected to the VPN ap I can trace route to 45.67.89.122 and the route goes via the VPN server.

However if while connected to the VPN ap I try and do a traceroute to my REAL internet address - 45.67.89.123 (PPPoE interface address) - I do not get the same behavior. I assume that this is because packets then end up in the input chain rather than the forward chain.

I think there may be things I can do with mangle rules IF all addresses were assigned statically ie both ends of the PPPoE and PPTP tunnels had static addresses. If that were the case then it looks like I might be able to write an INPUT rule that redirects traffic from the VPN ap aimed at my PPPoE external address to go via another address (I haven’t tried this - and I am not an expert!)

HOWEVER I can not assume the addresses are static (and I cant ask for static either other than my own PPPoE WAN address). So is there anyway of forcing traffic from the VPN Wireless access point that is aimed at my routers PPPoE WAN address to be FORWARDED by the router via the PPTP tunnel.

Why do it? I want to use Kalilinux tools to test the vunerability of my external facing firewall and the DMZ that I have. I also want to be able to test the webserver I run behind the firewall from the internet by using the VPN tunnel to first get out onto the internet.

Any ideas?

[Sob]

Interesting question. In theory, there are two ways how to do it, nice clean one with just routing and less elegant with NAT. And finally third, workaround, do it somewhere else.

The NAT way is simple and boring, just connect to some fake made-up address (which will make packets go to tunnel) and then on the other end of tunnel take packets to this address and dstnat them to your public address. The complication is when you don’t control the remote end of tunnel, then you can’t use this.

The routing way sounded much more interesting, so I played with it for a while, but I didn’t succeed. In theory, it should be doable, you just need to manipulate routing in right way, i.e. to ignore locally available address and use different routing table. I can create different routing table and can mark packets to use it (that’s what you do too), but local addresses seem to be special case and ignore this. I had a look how Linux (which RouterOS is based on) does this. It has special routing table “local” for local addresses. I’m pretty sure that RouterOS has the same thing internally. The difference is that Linux allows you to work with this table (change routing rules or the table itself), but RouterOS doesn’t. It looks like in RouterOS “local” routing table is hardcoded to always have the highest priority.

Working solution for you (just for testing) is to connect to VPN server directly from machine connected to LAN. Then your public address will be (to this machine) as remote as any other public address on internet and everything to it will go though tunnel.

[drdog]

Hi Sob, thanks for the reply.

I was kinda coming to the answer you gave regarding the routing - RouterOS deals with local addresses specially (and maybe rightly so)

An observation and a thought …

The observation:
I tried two mangle rules which had an interesting(?) effect - I was trying the standard 2 WAN 2 LAN marking/static routes solution

Mangle:
Traffic from VPN ap was prerouting marked “VPN”
Traffic from !(VPN ap) was prerouting marked “not VPN”

Static routes:
0.0.0.0/0, gateway: PPTP client, mark “VPN”
0.0.0.0/0, gateway: PPPoE client, mark “not VPN”

Interestingly when I did that, nothing worked If I tried to ping 8.8.8.8 from the RB then it said there was no route to host

If I changed the second static route to
0.0.0.0/0, gateway: PPPoE
then all came good EXCEPT traffic from VPN bridge destined for PPPoE client WAN address didn’t work

I do not understand the behaviour. I feels to me that I need a third rule for the RB to see the PPPoE client - but I cant work out the rule - its feels it is something like
“If coming internally from the RB itself then use PPPoE client” - but how you code that escapes me

The thought was …
I reckon VPN ap to PPPoE external address will be handled by the INPUT chain as it is traffic intended for one of the router’s addresses. So is there mangle rules that can trap VPN ap to PPPoE external address and redirect to the PPTP client (I think the answer is “Yes, if the PPTP client addresses are static.” I think you could use a rule to send to the PPTP server address … but that requires static addresses and I don’t think I have that luxury.)

Regarding VPN client on computer - yes, I remembered that as an option after spending far far too much time on solution where it was all done by RB. But I learned stuff trying to get RB routing solution to work, so it was not wasted time - and I would still like to get the RB routing solution to work - it is annoying me that I can’t when it feels that it might be achievable … or it might not be, for the reason suggested: the RB OS treats router addresses specially.

[msatter]

Look in the connections screen when you ping. You will see that your client IP is used as return IP (192.168.88.0/24 ) so Google does not know where to return their answer.

NAT will provide a reachable return IP and will be waiting at the supplied port for the answer to send it to your internal IP.

[Sob]

@msatter: It’s different problem. The goal here is very unusual. Router has public address and acts as VPN client. You can make all traffic from LAN to internet go through VPN tunnel. But there’s one exception - when destination is router’s own public address. Even if you mark routing for it to use VPN, router won’t send it there. Normally it’s logical thing, why to send the packet somewhere else, when destination address is right here. But sometimes, one user from million might want to do exactly that, take packet destined to local public address, send it to VPN and let it return back via primary connection and come to WAN interface. It looks like Linux can do it (I didn’t actually test it), but RouterOS can’t.

@drdog: Static or dynamic address makes no difference, both are local. And packet in input chain is result of routing decision, not the problem itself. You can mark routing for local destinations, but it’s basically ignored, because somewhere in RouterOS is implicit rule to first look up destination in “local” (hidden) routing table and only then process the other routing rules you can create.

[drdog]

OK - so it can be done … well, the answer doesn’t completely achieve my goal.

The solution is to put a prerouting mangle route rule in for the addresses that come from the VPN lan
The address that I used is the gateway address provided by the VPN tunnel - ie the VPN server

If the internet based VPN server offers a gateway address of 172.31.1.1
and
my VPN lan is 172.16.1.0/24
the rule would be

add action=route chain=prerouting passthrough=no route-dst=172.31.1.1 src-address=172.16.1.0/24

and that works wonderfully … if, on a device on VPN lan, I do a trace route to my PPPoE WAN address it goes via PPTP tunnel and back via several routers out on internet

except …

I need to know the VPN server gateway address - if the VPN disconnects and reconnects I do not know if I will get the same gateway address.

Ideally I would want to do something different here - having to type in an address is not what I want, I want something that uses a dynamic address obtained automatically from the PPTP client … but I can’t currently see a way of doing that that doesn’t involve going via the router

OR …

I have an event triggered script that gets the address of the PPTP gateway and amends the mangle rule …

Does RouterOS support event based triggering - a quick google suggests that isn’t possible …
Ok … so scheduled script then … once a minute maybe …

Now I’m off to learn Mikrotik scripting!

I’ll be back … not quite sure when though!

[Sob]

It looks like you were really determined to find solution. In hindsight, it’s obvious, even description in manual is very clear:

route - forces packets to a specific gateway IP by ignoring normal routing decision (prerouting chain only)

I knew that action=route existed, but I’ve never used it before for anything and the “ignoring normal routing decision” didn’t stick in my memory. Big thumbs up for finding it!

I don’t see event script option for VPN interfaces. But DHCP client has one and I think it’s not that long since it was added. And if it makes sense for DHCP, it would also make sense for VPN. You could try sending feature request to MikroTik.