OpenVPN Support Forum

Posted: **Thu Jan 14, 2016 7:09 am**

Hello, everyone.

FreeBSD host with 2 ethernet interfaces ( re0 and re1) connects to an OpenVPN server, upon connection interface tun0 gets created per my client config, the tunnel replaces default route. I guess it has "redirect-gateway def1" set in server config. It's all right, that was the idea.

So, originally Internet comes through re0 on the VPN-connecting machine. And re1 connects to LAN, for which VPN-connecting machine acts as a router.

My idea was to serve VPN tunnel as default gateway to LAN machines connected through eth1. But this doesn't work! As long as default gateway is through ethernet re0, LAN on eth1 has Internet all right. As soon as tun0 appears and default gateway is replaced with that through tun0, LAN on eth1 has no Internet.
At the same time, it's not a routing problem, since VPN network 172.16.55.0/24 can be pinged from LAN clients. I have NAT rules to translate addresses between LAN and VPN network (and other needed rules as well). Only Internet requests from LAN are not forwarded to tun0 on the VPN-connected machine and Internet hosts cannot be pinged.

QUESTION: is this a limitation of OpenVPN tunnels? Should bridged configuration (tap0 + re1) be used instead?
That'll be rather strange, for I've seen entire LANs sharing VPN-provided Internet.

Posted: **Thu Jan 14, 2016 12:22 pm**

Please see the Forum rules (top of page)

Posted: **Thu Jan 14, 2016 10:06 pm**

That's right, I've forgotten to post configs.

Please excuse my not having server config as I'm not the server admin/owner.
Also, my question is rather about the routing part so far. I just want to know if using default gw from tun0 for LAN on another interface on the same machine as tun0 is supposed to work.

Or perhaps there might be some server-side security features preventing this from working. Or maybe gateway forwarding like this is not possible except using bridged configuration. I just want to get this clear to start with, and if the answer is "possible", then I'll be very thankful if you point to any flaws in my PF config.

But if you tell me you absolutely need server config for further diagnosis, I'll ask the server owner. It's just that I've given him enough trouble so far and would like to clear up some general questions first, if you please.

Here's my /etc/pf.conf:

Code: Select all

out_if = "re1"
vpn_if = "tun0"
wir_if = "re0"

set block-policy return
set skip on lo0

nat on $out_if from 192.168.24.0/24  to any -> ($out_if)
nat on $wir_if from 192.168.26.0/27 to any -> ($wir_if)
nat on $out_if from 172.16.55.0/24 to any -> ($out_if)
nat on $vpn_if from any to 172.16.55.0/24 -> ($vpn_if)
nat on $out_if from any to 192.168.26.0/27 -> ($out_if)
#rdr pass on $out_if proto { tcp,udp } from 192.168.26.0/27 to 0.0.0.0 -> 172.16.55.2
anchor openvpn

pass in quick on $wir_if from any to any
pass out quick on $wir_if from any to any
pass in quick on $out_if from any to any
pass out quick on $out_if from any to any

block in quick all
block out quick all

In here wired iface re0 receives Internet from router. Wired iface re1 is connected to LAN where I want to forward Internet connection from tun0, just like normal default gw is successfully forwarded there with "normal" wired configuration.

And for "anchor openvpn" I have this in a separate file to be loaded when tun0 is up:

Code: Select all

pass out quick on tun0 from any to any keep state
pass in quick on tun0 from any to any keep state

Now here's routing table w/no VPN connection:

Code: Select all

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.24.1       UGS         re0
127.0.0.1          link#3             UH          lo0
192.168.24.0/24    link#1             U           re0
192.168.24.103     link#1             UHS         lo0
192.168.26.0/27    link#2             U           re1
192.168.26.1       link#2             UHS         lo0

Then here's the same when VPN is up:

Code: Select all

Internet:
Destination        Gateway            Flags     Netif Expire
default            172.16.55.1        UGS        tun0
$my_server_net   192.168.24.1       UGS         re0
127.0.0.1          link#3             UH          lo0
172.16.55.0/24     172.16.55.2        UGS        tun0
172.16.55.1        link#4             UH         tun0
172.16.55.2        link#4             UHS         lo0
192.168.24.0/24    link#1             U           re0
192.168.24.103     link#1             UHS         lo0
192.168.26.0/27    link#2             U           re1
192.168.26.1       link#2             UHS         lo0

Here "$my_server_net 192.168.24.1" is the route through my wired gw to the VPN server's public IP.

Here is the client conf I'm using:

Code: Select all

client
dev tun
proto udp
remote $myserver $myport
nobind
persist-tun
cipher AES-256-CBC
verb 2
mute 3
push-peer-info
ping 10
ping-restart 60
server-poll-timeout 3
reneg-sec 2592000
sndbuf 100000
rcvbuf 100000
remote-cert-tls server
comp-lzo no
auth-user-pass
<ca>
-----BEGIN CERTIFICATE-----
[here goes certificate]...
-----END CERTIFICATE-----
</ca>
key-direction 1
<tls-auth>
#
# 2048 bit OpenVPN static key
#
[here goes static key]..
-----END OpenVPN Static key V1-----
</tls-auth>
<cert>
-----BEGIN CERTIFICATE-----
[here goes certificate]
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...[here goes private key]
-----END PRIVATE KEY-----
</key>

Of course, I've hidden the real server IP and port.

Per my NAT rules I expect to forward VPN network 172.16.55.0/24 to LAN 192.168.28.0/27. When tun0 is up 172.16.55.1 replaces default gw on the VPN-connected machine.
With NAT translation in both ways between VPN net and target LAN I expect this default gw to be forwarded to LAN just the way normal gw is forwarded in case of wired connection. In which case a LAN machine needs no other routes but LAN + gw belonging to LAN. The rest of the routing and forwarding is done on the router machine.

Posted: **Thu Jan 14, 2016 10:46 pm**

KBerger wrote:FreeBSD host

Oh dear .. With iptables this is a snap ..

I think you are on the right lines but I don't know enough about freebsd .. sorry.

FYI: You do not need a bridge for your LAN clients to use the internet via your router
(The answer is in the name router)

Posted: **Thu Jan 14, 2016 11:00 pm**

Well, it's somewhat different it is true.

But I can say that I can PING the VPN network from the target LAN. Actually, tun0 has local IP 172.16.55.2 and default gw is (remote) 172.16.55.1. Both things are reachable from LAN, as ping shows. Which proves to me NAT translation works.

But then, if this default gw IP is reachable from LAN, it only means the router FreeBSD host isn't using this as default gw for LAN clients, while it does apply it for localhost-originating requests!

Posted: **Thu Jan 14, 2016 11:07 pm**

Please post your client log at --verb 4 .. may be there is something a miss ..

Posted: **Fri Jan 15, 2016 11:44 am**

As puzzling the problem was, the solution is just as simple.

There must have been some deficiency in my ruleset formulation. I simplified it now, though idea remains the same -- and all works.
Here it is:

Code: Select all

set block-policy return
set skip on lo0

nat on re0 from ! re0  to any -> (re0)
nat on re1 from ! re1 to any -> (re1)
nat on tun0 from ! tun0 to any -> (tun0)

anchor openvpn

pass in quick on re1 from any to any
pass out quick on re1 from any to any
pass in quick on re0 from any to any
pass out quick on re0 from any to any

block in quick all
block out quick all

The syntax is self-explanatory and in line with NAT logic: on a given interface all traffic coming from other interfaces to be NATed to this one.

It just seems like the explicit mentioning of networks (as in 192.168.1.0/24) doesn't cover all traffic to be covered. But in this more generalized form it includes all you need.

Posted: **Fri Jan 15, 2016 11:47 am**

So don't you think it snaps here as well

?

Posted: **Fri Jan 15, 2016 11:59 am**

A Snap, sure ..

Thanks for letting us know your solution

Marking as solved and closing.

Regards

OpenVPN Support Forum

[Solved] Routing vs Bridging question - FreeBSD pf NAT

[Solved] Routing vs Bridging question - FreeBSD pf NAT

Re: Routing vs Bridging -- question

Re: Routing vs Bridging -- question

Re: Routing vs Bridging -- question

Re: Routing vs Bridging -- question

Re: Routing vs Bridging -- question

Re: Routing vs Bridging -- question

Re: Routing vs Bridging -- question

Re: Routing vs Bridging -- question