Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Thu Apr 8 14:01:09 2010 client2/x.x.x.116:45573 MULTI: bad source address from client [x.x.x.116], packet dropped
As OpenVPN is a router when used in tun server mode, you need to set up the route table on the OpenVPN server process, in addition the kernel route table. Use the "iroute" directive in a client specific config file.
Or use OpenVPN in peer-to-peer mode.
And don't put MASQURADE rules on the LAN interface (eth1), they will just cause problems.
Here is my server.conf file, on the machine with eth0 being the public IP, and eth1 being 10.10.202.1, on the box vpn01:
Code:
port 1194
proto tcp-server
dev tun
tls-server
# our keys and certificate files
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/vpnserver.crt
key /etc/openvpn/keys/vpnserver.key
dh /etc/openvpn/keys/dh1024.pem
tls-auth /etc/openvpn/keys/ta.key 0
# 192.168.207.1 is our local VPN endpoint (local location)
# 192.168.207.2 is the remote endpoint (remote location)
ifconfig 192.168.207.1 192.168.207.2
# our up script will establish routes
# once the VPN is active
up ./remote.up
push "redirect-gateway def1"
# force the clients to use the internal LAN's DNS and WINS servers
push "dhcp-option DNS 192.168.1.22"
push "dhcp-option DNS 192.168.1.23"
push "dhcp-option WINS 192.168.1.22"
# advertise the routes for the LANs that we want the client to access
push "route 192.168.1.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0"
push "route 10.10.4.0 255.255.252.0"
push "route 10.10.202.0 255.255.255.0"
keepalive 10 120
cipher AES-256-CBC
comp-lzo
max-clients 2
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
mute 20
chroot /etc/openvpn/
The routing table when the OpenVPN service is running on the server:
Code:
[root@vpn01 openvpn]# ip route show
192.168.207.2 dev tun0 proto kernel scope link src 192.168.207.1
X.X.X.112/29 dev eth0 proto kernel scope link src X.X.X.115
10.10.202.0/24 dev eth1 proto kernel scope link src 10.10.202.2
192.168.204.0/24 via 192.168.207.2 dev tun0
169.254.0.0/16 dev eth1 scope link
default via 10.10.202.1 dev eth1
On my client machine (vpn02), with a public IP on the eth0 interface, and 192.168.204.1 on the eth1 interface:
Code:
client
dev tun
proto tcp-client
# the server and port we're connecting to
remote x.x.x.x 1194
# 192.168.207.2 is our local VPN endpoint (Eagle Rock Library)
# 192.168.207.1 is the remote VPN endpoint (Court House server room)
ifconfig 192.168.207.2 192.168.207.1
# our script will establish routes
# once the VPN is up
up ./local.up
resolv-retry infinite
nobind
persist-key
persist-tun
tls-client
ca ca.crt
cert client2.crt
key client2.key
tls-auth ta.key 1
ns-cert-type server
cipher AES-256-CBC
comp-lzo
user nobody
group nobody
status openvpn-status.log
verb 3
mute 20
chroot /etc/openvpn/
The route and IP information of everything on vpn02 (client):
Code:
[root@vpn02 openvpn]# ip route show
192.168.207.1 dev tun0 proto kernel scope link src 192.168.207.2
x.x.x.115 via x.x.x.113 dev eth0
x.x.x.112/29 dev eth0 proto kernel scope link src x.x.x.116
192.168.2.0/24 via 192.168.207.1 dev tun0
192.168.1.0/24 via 192.168.207.1 dev tun0
10.10.202.0/24 via 192.168.207.1 dev tun0
192.168.204.0/24 dev eth1 proto kernel scope link src 192.168.204.1
10.10.4.0/22 via 192.168.207.1 dev tun0
169.254.0.0/16 dev eth1 scope link
0.0.0.0/1 via 192.168.207.1 dev tun0
128.0.0.0/1 via 192.168.207.1 dev tun0
default via x.x.x.113 dev eth0
With the VPN disconnected, I can browse the web from the client. Once I connect the client to the VPN, I can no longer browse the web.
I can ping across the tunnel in both directions. From the client machine, I can traceroute to the OpenVPN server's default gateway:
Code:
[root@vpn02 openvpn]# traceroute 10.10.202.1
traceroute to 10.10.202.1 (10.10.202.1), 30 hops max, 40 byte packets
1 (192.168.207.1) 0.998 ms 17.257 ms 17.222 ms
2 (10.10.202.1) 17.219 ms 17.208 ms 17.186 ms
Ok, so it was a firewalling issue, I removed the following line:
Code:
-A FORWARD -s ! 10.10.202.0/255.255.255.0 -i eth1 -j DROP
and I was able to pull up a webpage on the client while it was connected to the VPN.
However, I still have a firewall issue of some sorts that blocking web access from the 192.168.204.0 range.
I connected a Windows XP laptop up to my OpenVPN client server (it's running dhcpd handing out 192.168.204.0 addresses) and I verified the client PC is getting an IP, but I can't browse the web from it.
To check further, from the OpenVPN client machine I can ping google by IP, but I can not from my XP laptop that's connected to it.
And whereas I can ping 10.10.202.1 from the OpenVPN client/server, I can not from the XP laptop. So for some reason it looks as if there is a disconnect between 192.168.204.1 and anything else.
And to confuse me further, I can ping both 192.168.204.1 (the client/server) and 192.168.204.254 (the IP of my XP laptop) from the other end of the tunnel. So since that's the case, it seems the routing is fine, I just have a firewall issue still somewhere. When the VPN isn't up, the laptop can get out to the Internet fine.
Ok, I found the disconnect here. What I've drawn out below is my ping testing. Double sided arrows means I was able to ping these IP's in both directions:
So obviously the fact that the 192.168.204.0/24 traffic can't make it to 10.10.202.1 is not good, but I don't understand how that is if it can hit 10.10.202.2.
And I wonder why 192.168.207.2 and 192.168.207.1 can ping 10.10.202.1, but not the other way around.
I'm curious to know why you used tunnelling at all? Bridging gives much more flexibility IMO.
The reason why I went that route is because from what I have been reading, tunneling doesn't have as much overhead as bridging does. I don't know from experience, as this is my first attempt at putting together a site-to-site VPN.
Fair enough. Bridging can seem to be a little bit involved too, as far as the neophyte is concerned. Do give it a try though... use is much more transparent.
My laptop automatically connects to 4 or 5 bridged VPNs whenever they are available... I take care that they are on different segments as each other, but I can access any machine on any of the VPNs as if I was in the office.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
