[Solved] Routing vs Bridging question - FreeBSD pf NAT
Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech
-
- OpenVPN User
- Posts: 31
- Joined: Wed Mar 16, 2011 1:27 pm
[Solved] Routing vs Bridging question - FreeBSD pf NAT
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.
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.
- Traffic
- OpenVPN Protagonist
- Posts: 4066
- Joined: Sat Aug 09, 2014 11:24 am
Re: Routing vs Bridging -- question
Please see the Forum rules (top of page)
-
- OpenVPN User
- Posts: 31
- Joined: Wed Mar 16, 2011 1:27 pm
Re: Routing vs Bridging -- question
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: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:
Now here's routing table w/no VPN connection:
Then here's the same when VPN is up:
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: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.
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
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
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
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 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>
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.
- Traffic
- OpenVPN Protagonist
- Posts: 4066
- Joined: Sat Aug 09, 2014 11:24 am
Re: Routing vs Bridging -- question
Oh dear .. With iptables this is a snap ..KBerger wrote:FreeBSD host
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)
-
- OpenVPN User
- Posts: 31
- Joined: Wed Mar 16, 2011 1:27 pm
Re: Routing vs Bridging -- question
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!
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!
- Traffic
- OpenVPN Protagonist
- Posts: 4066
- Joined: Sat Aug 09, 2014 11:24 am
Re: Routing vs Bridging -- question
Please post your client log at --verb 4 .. may be there is something a miss ..
-
- OpenVPN User
- Posts: 31
- Joined: Wed Mar 16, 2011 1:27 pm
Re: Routing vs Bridging -- question
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: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.
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
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.
-
- OpenVPN User
- Posts: 31
- Joined: Wed Mar 16, 2011 1:27 pm
Re: Routing vs Bridging -- question
So don't you think it snaps here as well ?
- Traffic
- OpenVPN Protagonist
- Posts: 4066
- Joined: Sat Aug 09, 2014 11:24 am
Re: Routing vs Bridging -- question
A Snap, sure ..
Thanks for letting us know your solution
Marking as solved and closing.
Regards
Thanks for letting us know your solution
Marking as solved and closing.
Regards