Routing all traffic through a VPN tunnel

T

telecommand

Hello,

I've recently set up an OpenVPN tunnel and would like to route the entire traffic of a client (Windows) through a server (FreeBSD). My goal is that all internet applications on the client (e.g. browser, chat, games) connect to the internet using the IP address of the server rather than the client's IP.

The static OpenVPN tunnel I've configured seems to work nicely, the server side uses "ifconfig 10.0.8.1 10.0.8.2" and the client side "ifconfig 10.0.8.2 10.0.8.1". On the server, a "ping 10.0.8.2" reaches the client (and a "ping 10.0.8.1" works fine on the client). Furthermore, I use "redirect-gateway def1" on the Windows client in order to route all outgoing IP traffic through the VPN (according to "ipconfig", the default gateway is activated successfully on the Windows client).

Because of missing FreeBSD know-how, I was not able to configure the server side so far. There are some forums and wikis which describe the necessary steps on the server side for Linux, but I couldn't find anything for FreeBSD. Under Linux, something like this seems to be sufficient:

echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.8.0/24 -j MASQUERADE

How do I achieve a similar effect under FreeBSD (using ipfw and/or natd)? Any help is appreciated.

Thanks,
TC.
 
Code: 
# echo gateway_enable=\"YES\" >> /etc/rc.conf
# echo firewall_enable=\"YES\" >> /etc/rc.conf
# echo firewall_script=\"/path/to/file/with/rules\" >> /etc/rc.conf
# sysctl net.inet.ip.forwarding=1
# kldload ipfw.ko
# kldload ipfw_nat.ko


Firewall script:
Code: 
ipfw nat 1 config if tun0

# ...usual ipfw rules
ipfw add nat 1 all from 10.0.8.0/24 to any xmit tun0
ipfw add nat 1 all from any to me recv tun0
# ...rules continued

Reading ipfw(8) and handbook will be also helpful.

P.S.: After kldload ipfw.ko by default all packets will be dropped, so you can lock out machine if you working through ssh
 
hurricane_sh, you better re-check if all of your traffic is passing through the tunnel, I seriously doubt that :). Unless you are using live IPs in your tunnel configuration.
 
I know - this is an old thread but I tried the same and it doesn´t work.

I want to use my FreeBSD server as gateway for the whole network to a VPN tunnel. The VPN tunnel is up and works fine on the FreeBSD server. All traffic from the FreeBSD server to the Internet goes through the VPN tunnel. Now I want to route all my clients traffic through the VPN tunnel on the FreeBSD server.

LAN Network: 192.168.178.0/24
Clients: 192.168.178.50 - 192.168.178.150
FreeBSD Server: 192.168.178.32
Router: 192.168.178.1

ifconfig
Code: 
freebsd# ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
        ether 00:30:18:4a:ec:d7
        inet6 fe80::230:18ff:fe4a:ecd7%em0 prefixlen 64 scopeid 0x1
        inet 192.168.178.32 netmask 0xffffff00 broadcast 192.168.178.255
        inet6 2002:5eda:c88c:0:230:18ff:fe4a:ecd7 prefixlen 64 autoconf
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
ipfw0: flags=8801<UP,SIMPLEX,MULTICAST> metric 0 mtu 65536
tun0: flags=8043<UP,BROADCAST,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet6 fe80::230:18ff:fe4a:ecd7%tun0 prefixlen 64 scopeid 0x7
        inet 5.5.8.31 netmask 0xfffff800 broadcast 5.5.15.255
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
        Opened by PID 43870
netstat
Code: 
freebsd# netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
0.0.0.0/1          5.5.8.1            UGS         1     1924   tun0 =>
default            192.168.178.1      UGS         0    40310    em0
5.5.8.0/21         link#7             U           0        0   tun0
5.5.8.31           link#7             UHS         0        0    lo0
46.17.100.230/32   192.168.178.1      UGS         1     2605    em0
127.0.0.1          link#5             UH          0    14201    lo0
128.0.0.0/1        5.5.8.1            UGS         0      283   tun0
192.168.178.0/24   link#1             U           3    37002    em0
192.168.178.32     link#1             UHS         0        0    lo0

As I said, all traffic from the FreeBSD server to the Internet goes direct through the VPN server as it should. But I can´t go online on a Windows client with the FreeBSD server as gateway.

Nat is running on tun0:
Code: 
freebsd# ps -auxw | grep nat
root    1138  0.0  0.1  3440  1332  ??  Is    7:42PM   0:00.00 /sbin/natd -dynamic -m -n tun0

IPFW rules:
Code: 
freebsd# ipfw show
00100  28600  2585008 allow ip from any to any via lo0
00200      0        0 deny ip from any to 127.0.0.0/8
00300      0        0 deny ip from 127.0.0.0/8 to any
00400      0        0 deny ip from any to ::1
00500      0        0 deny ip from ::1 to any
00600      5      344 allow ipv6-icmp from :: to ff02::/16
00700      0        0 allow ipv6-icmp from fe80::/10 to fe80::/10
00800    274    35160 allow ipv6-icmp from fe80::/10 to ff02::/16
00900      0        0 allow ipv6-icmp from any to any ip6 icmp6types 1
01000      0        0 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136
65000 174545 18717022 allow ip from any to any
65100      0        0 nat 1 ip from 192.168.178.0/24 to any xmit tun0
65200      0        0 nat 1 ip from any to me recv tun0
65535      0        0 deny ip from any to any

I created the rule 65100 and 65200.
Code: 
ipfw add nat 1 all from 192.168.178.0/24 to any xmit tun0
ipfw add nat 1 all from any to me recv tun0
But rule 65000 catches it before and this is the main problem? I can´t find the error after some hours of research now.

So thanks for any help!
 
You must log in or register to reply here.
Back
Top