OpenVPN issue connection to remote LAN

t0ken

t0ken

Hey all.

Let me first say that I enjoy using FreeBSD as a server platform and ever since I've gotten over the learning curve (coming from Linux) I can never see myself running a Linux server in favor of FreeBSD. It's light, fast, and includes jails & zfs!

Now that that's out of the way, let's get down to my issue. I recently have reinstalled my servers that were previously running Mandriva Linux with FreeBSD 8.0 x86_64. For the most part, everything went smoothly (sans building Citadel on FreeBSD, but hey, it gave me a chance to install & run postfix/dovecot/mysql).

I ran openvpn on my server prior to switching from Linux. I was able to save all my config files and ssl files and simply copied them over from backups. In doing so, I got a semi-working openvpn system. There's just one problem, I cannot ping any other computer on the remote LAN other than my VPN server (both the VPN NIC and Internal NIC). I am able to ping between VPN clients as well.

I'll list here all of the info that I think is relevant, let me know if there's anything else you'd like to see.

LAN: 10.0.0.96/27, router (10.0.0.97) configured to route 172.16.254.0/24 traffic to 10.0.0.99
VPN server: 10.0.0.99, 172.16.254.1, FreeBSD-8.0
VPN clients: 172.16.254.6, 172.16.254.10, both running Linux

Client conf file:
Code: 
client
dev tun                                     
proto udp                             
remote drenet.homelinux.net 1194         
resolv-retry infinite                            
nobind                              
persist-key                                  
persist-tun                                  
ca /etc/openvpn/ca.crt               
cert /etc/openvpn/laptop.crt
key /etc/openvpn/laptop.key
ns-cert-type server
comp-lzo
verb 3

Server conf file:
Code: 
local 10.0.0.99
port 1194
proto udp
dev tun
ca /etc/ssl/openvpn/ca.crt
cert /etc/ssl/openvpn/server.crt
key /etc/ssl/openvpn/server.key
dh /etc/ssl/openvpn/dh1024.pem
ifconfig-pool-persist /usr/local/etc/openvpn/ipp.txt
server 172.16.254.0 255.255.255.0
keepalive 10 120
client-to-client
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4
push "route 10.0.0.96 255.255.255.224"

Client routes:
Code: 
[root@dlaptop andre]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.16.254.9    *               255.255.255.255 UH    0      0        0 tun0
10.0.0.96       172.16.254.9    255.255.255.224 UG    0      0        0 tun0
10.3.200.0      *               255.255.255.0   U     35     0        0 wlan0
172.16.254.0    172.16.254.9    255.255.255.0   UG    0      0        0 tun0
link-local      *               255.255.0.0     U     35     0        0 wlan0
default         10.3.200.1      0.0.0.0         UG    35     0        0 wlan0

Server routes:
Code: 
daemon# netstat -r
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            ddwrt              UGS        42  6965158   nfe0
10.0.0.96/27       link#1             U           2  9787019   nfe0
daemon             link#1             UHS         0   126322    lo0
squid              link#1             UHS         0     8651    lo0
mysql              link#1             UHS         0    11943    lo0
dns                link#1             UHS         0    31926    lo0
mail               link#1             UHS         0   100744    lo0
apache             link#1             UHS         0    12500    lo0
localhost          link#2             UH          0     7594    lo0
172.16.254.0       172.16.254.2       UGS         0     6113   tun0
172.16.254.1       link#4             UHS         0        0    lo0
172.16.254.2       link#4             UH          0        0   tun0

tcpdump on VPN server during ping from 172.16.254.9(client) to 10.0.0.100(LAN node) (according to client, all packets drop):
Code: 
daemon# tcpdump -n -i tun0 not port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
08:56:14.890462 IP 172.16.254.10 > 10.0.0.100: ICMP echo request, id 38171, seq 1, length 64
08:56:15.901302 IP 172.16.254.10 > 10.0.0.100: ICMP echo request, id 38171, seq 2, length 64
08:56:16.891332 IP 172.16.254.10 > 10.0.0.100: ICMP echo request, id 38171, seq 3, length 64
08:56:17.891211 IP 172.16.254.10 > 10.0.0.100: ICMP echo request, id 38171, seq 4, length 64
08:56:18.890815 IP 172.16.254.10 > 10.0.0.100: ICMP echo request, id 38171, seq 5, length 64
08:56:19.890280 IP 172.16.254.10 > 10.0.0.100: ICMP echo request, id 38171, seq 6, length 64
08:56:20.890248 IP 172.16.254.10 > 10.0.0.100: ICMP echo request, id 38171, seq 7, length 64
08:56:21.890216 IP 172.16.254.10 > 10.0.0.100: ICMP echo request, id 38171, seq 8, length 64
08:56:22.890696 IP 172.16.254.10 > 10.0.0.100: ICMP echo request, id 38171, seq 9, length 64
08:56:23.890196 IP 172.16.254.10 > 10.0.0.100: ICMP echo request, id 38171, seq 10, length 64



One thing I notice, is that on both the Client(s) and Server, I see that there are two IP addresses given. For example, here's an ipconfig -a on my laptop (client; impertinent info removed):
Code: 
[root@dlaptop andre]# ifconfig -a
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host     
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:4080 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4080 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0                              
          RX bytes:222744 (217.5 KiB)  TX bytes:222744 (217.5 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:172.16.254.10  P-t-P:172.16.254.9  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1743 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1946 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:530612 (518.1 KiB)  TX bytes:115178 (112.4 KiB)

wlan0     Link encap:Ethernet  HWaddr 00:1F:3A:86:91:ED
          inet addr:10.3.200.115  Bcast:10.3.200.255  Mask:255.255.255.0
          inet6 addr: fe80::21f:3aff:fe86:91ed/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:48361 errors:0 dropped:0 overruns:0 frame:0
          TX packets:40144 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:43255598 (41.2 MiB)  TX bytes:4785348 (4.5 MiB)

Could that have anything to do with it? Thanks in advance for the help!
 
Most likely you forgot to enable routing. Add to /etc/rc.conf:
Code: 
gateway_enable="YES"

This is similar to Linux' [cmd=]echo 1 > /proc/sys/net/ipv4/ip_forward[/cmd]
 
Just to make sure: is IP-forwarding on on the server?
[cmd=]sysctl net.inet.ip.forwarding[/cmd] (indeed: enabled by gateway_enable or by setting the sysctl in sysctl.conf)
 
doh! Should've known that!

Anyways, I've added the above (first 'gateway_enable="YES"' in rc.conf, then 'net.inet.ip.forwarding=1' in sysctl.conf, then both) and restarted the openvpn service on both the client and server each time I changed rc.conf or sysctl.conf, and I'm still getting the same issue.

Do I have to restart the box the openvpn server is running on for the settings to take affect?
 
Did you actually restart sysctl (# /etc/rc.d/sysctl restart) or perform the [cmd=]sysctl net.inet.ip.forwarding=1[/cmd] command manually?
 
t0ken said:
Anyways, I've added the above (first 'gateway_enable="YES"' in rc.conf, then 'net.inet.ip.forwarding=1' in sysctl.conf, then both)
Click to expand...
That's a bit overkill. The gateway_enable actually sets that sysctl during boot.
 
You must log in or register to reply here.
Back
Top