# Connect to server after VPN connection establishd on server



## shahab (Jan 3, 2019)

Hello great community of FreeBSD,

Recently I have moved to FreeBSD and am loving it. I have this server at home that is connected to the internet through a router:

```
,----------------.                           ,-------------.
| FreeBSD server | < ----- local net ----- > | Home Router | ..... public IP
`----------------'                           `-------------'
```
When I establish a VPN connection on this server, I am no longer able to access the services (such as ZNC) through the public IP anymore. The reason is obvious and there are a few solutions for GNU/Linux:

ssh into a server which is connected to a VPN service

I wonder how I can achieve the same on my FreeBSD machine.

*TLDR*
More on my configuration: On this server, I have some programs accessing the internet through my public IP and some other through a VPN server:

```
,----------------.
                    | FreeBSD server |
                    |                |
openvpn server <----|-prog1    prog2-|----> public ip
                    `----------------'
```
I have achieved this by:

```
echo "net.fibs=2" >> /boot/loader.conf
reboot

# the IPs below are fictitious
route add -host 192.168.1.15 -iface lo0 -fib1  # server's local IP
route add default 192.168.1.1 -fib 1           # home router IP

setfib 1 openvpn-client /path/to/udp.conf

# reutrns my home router's public IP
curl ifconfig.co

# returns the VPN IP address
setfib 1 curl ifconfig.co

# the actuall service I am interested in
setfib 1 /usr/local/etc/rc.d/znc start
```

Now, I can access my ZNC bouncer from my local network and indeed it connects to other IRC servers using the VPN. However, if I am outside the local network (say at work), I cannot access the ZNC. Obviously I have configured the home router to port-forward to ZNC. That setup is fine. In other words, if ZNC is run without VPN then I am able to access it from outside network.

Last but not least, I am using FreeBSD 11.2-RELEASE-p7

Thank you in advance for taking the time to read this.


----------



## VladiBG (Jan 3, 2019)

Search google for vpn split-tunneling and you will find the answer of your question.


----------



## shahab (Jan 4, 2019)

VladiBG said:


> Search google for vpn split-tunneling and you will find the answer of your question.


I believe I need "symmetric routing enforcement". Apparently the OP here and here has found a solution but the original link is dead.


----------



## mvanbaak (Jan 4, 2019)

The original link can be found in the official archives: https://marc.info/?l=openbsd-misc&m=118445562925908&w=4


----------



## shahab (Jan 4, 2019)

Thank you mvanbaak. Until I come up with a "firewall" solution, I post my hacky solution here:

I have used socat to contain this problem:

```
# router port-forwards external incoming connections to port 1234 in this example
socat tcp-listen:1234,bind=192.168.1.15,reuseaddr,fork tcp:127.0.0.1:5678
```


```
me@work <---internet---> home router <---local net---> socat@192.168.1.15 <---loopback---> znc@127.0.0.1
```
this is tricking the ZNC server to think the incoming connection is coming from a loopback interface and that's where it reply back to. socat is keeping the sessions here and handling them. In other words, I used socat to masquerade the incoming connections. There is 2 side backs to this though:
1) Extra layer
2) In ZNC log, incoming IP's are not the actual ones anymore


----------



## SirDice (Jan 4, 2019)

It's not really a firewall or a VPN issue, it's a routing issue. You've set your default gateway to the tunnel end-point. Which means all your traffic is routed through that tunnel. What you should do is to route _only_ the VPN network to the other side of the tunnel, leave your default gateway as-is.

This will cause traffic destined for your server to be routed through the tunnel while all your other traffic gets sent to your default gateway (which is typically your ISP). There's no need for multiple routing tables either. The single 'standard' routing table is all that's required.


----------



## shahab (Jan 4, 2019)

SirDice,



SirDice said:


> It's not really a firewall or a VPN issue, it's a routing issue. You've set your default gateway to the tunnel end-point. Which means all your traffic is routed through that tunnel. What you should do is to route _only_ the VPN network to the other side of the tunnel, leave your default gateway as-is.



No. I actually want this to happen. Let me rephrase the situation:

1) I have default route table (fib 0) that uses my ISP internet
2) I have a 2nd route table (fib 1) that every traffic in it is supposed to go through the VPN
3) most programs use fib 0, aka my ISP internet, to access the net. like: pkg, ntp, etc
4) a special set of programs like torrent client are supposed to fully use the VPN traffic (fib 1)

My problem arises as a hybrid of (3) and (4): Although I want my ZNC IRC bouncer to access the net through VPN, but I want it to reply back to it's user's incoming connections through the same interface it receives it. Maybe it is not clear what ZNC is or what it does. I hope this helps (sorry for the wide ASCII drawing):

```
user1 ... internet ...
                      \  ,-------.      ,--------.      ,----------------------.      ,----.
                        (public ip) ====| router | ==== | ZNC @ FreeBSD server | ....(vpn ip)..... internet .... IRC servers
user2 ... internet .../  `-------'      `--------'      `----------------------'      `----'


a) <========================= users managing their IRC bouncer ================>
b)                                                      <................ IRC bouncer connecting to IRC servers ............>
c) <----------------------------------------------- users sending and receiving texts from IRC channels -------------------->
```

If ZNC would support SOCKS for outbound/IRC connections, this problem wouldn't exist in the first place. However, I am not looking for a replacement or things like that. I think this is an interesting problem on its own and deserve a solution, specially for laymen like me.


----------

