RE: OpenVPN and IP Forwarding
Hi,
>>>http://i1309.photobucket.com/albums/s629/CletusJenkins/network_zps9f815828.png
>>
>>This helped a lot.
>>Now me, I have the VPN server running on the "router" machine and the client on the side of the end users. But if you are the only user then this should work too, it is just a bit confusing for me.
>>
>>[....]
>>
>>> Anyway, here is an of my openvpn config (domain names expunged):
>>
>>The openvpn server side config is important too, even more, but.... As you said, the OpenVPN tunnel is working so it is just a routing issue.
>
>The VPN Server is a black box to me unfortunately. It is in another country. I just rent the vpn service from its owners,
> perhaps they could give me their server config, or at least the bits relevant to my connection to them.
> I hadn't thought to ask them. Mainly because the VPN tunnel works great, as long as one is logged into my "router" machine or the wireless laptop I am writing this from.
Hmm, hold on, I think I am getting a better picture of the situation too. ;-)
Aha, you are located at the place of "my router" and the "local LAN". I thought that was a network you were trying to manage remote via the VPN. Ok, that makes it a bit more clear what you are trying to achieve.
> The VPN server is just one machine, yours, and not part of another local network right?
> We are trying to solve a routing problem from ONE machine, the VPN server,
> to the network on the private network other side of the VPN right?
So maybe we are trying to solve something a bit different.
>Before bringing up the VPN I have this routing table (not the real routable IPs):
>
>Destination Gateway Genmask Flags MSS Window irtt Iface
>66.55.44.30 0.0.0.0 255.255.255.252 U 0 0 0 eth1
>192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
>0.0.0.0 66.55.44.33 0.0.0.0 UG 0 0 0 eth1
>
>So the next to last line points back to my local lan. When I bring up the vpn the following is the route table:
Looks normal to me, your eth1 is directly connected to the internet, your eth0 is connected to your local LAN. The router at the ISP is at .33 of the network where you have .30
[....]
> I noticed something odd after a reboot to clear any routing weirdness,
> I can't ping the systems on the private network from my "router" whether the vpn is up or not.
> Is this normal? Looking closer at my route table (before the vpn is started), it seem odd:
Yes you should be able to ping the machines unless there is something preventing it.
Are all machines on the Local LAN (Debian) Linux machines? If they are Windows machines, those block ICMP ping traffic by default these days.
If they are Linux then you may have a firewall but, usually, by default there is none enabled.
Your router machine is Linux and you probably have a firewall there. ;-)
Which package are you using? Or are you, like me, writing your own iptables script?
Do the other machines on the Local net have a firewall too? Probably not but..... check that
On your router machine the firewall should allow ICMP traffic at least from / to your local LAN.
Assuming you have a pretty basic iptables firewall. You probably have something like:
IPTABLES=/sbin/iptables
# Set policies
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
# Flush all rules in all chains and then delete all chains
chains=`cat /proc/net/ip_tables_names 2>/dev/null`
for i in $chains; do $IPTABLES -t $i -F; done
for i in $chains; do $IPTABLES -t $i -X; done
# Reset all counters for default chains
$IPTABLES -Z
And then accept what you do want to go through. Like normal return traffic and the loopback device:
KEEPSTATE=" -m state --state ESTABLISHED,RELATED"
# Accept return traffic.
$IPTABLES -A FORWARD -j ACCEPT $KEEPSTATE
$IPTABLES -A INPUT -j ACCEPT $KEEPSTATE
# Loopback interface always accept
$IPTABLES -A INPUT -i lo -j ACCEPT
What you then need too is something like:
# We accept ping etc to this machine
$IPTABLES -A INPUT -p icmp -j ACCEPT
Or
# We accept ping etc to this machine from the local LAN (eth0)
$IPTABLES -A INPUT -i eth0 -p icmp -j ACCEPT
You also need to
# Forward traffic from your local LAN to the outside
$IPTABLES -A FORWARD -i eth0 -j ACCEPT
After that you have a basic running firewall that should allow "normal traffic" to the router machine and to the outside.
I assume you already have a running setup so forwarding on the router machine is already on, right?
Either in /etc/sysctl.conf
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
Or in your firewall script near the end
# Forwarding can be enabled, firewall is up
echo 1 > /proc/sys/net/ipv4/ip_forward
> Is it saying send anything destined for 192.168.2.0/8 through eth1, my real, routable network interface?
> Shouldn't it go through the interface that is actually connected to the local lan, eth0?
Yes, your "default" routing lines should point to the interface where that network is connected to. Are you sure they are mixed up?
Do you configure your NICs via the /etc/network/interfaces file? What does it look like?
> I noticed a notational mistake in my original question, the local lan is 192.168.2.0/24 not 192.168.2.0/8,
> its been such a long time since I used CIDR notation I got it part after the slash backwards.
No problem, I got that. ;-) Did not even notice you got it wrong as I assumed it was a C-class network.
Let us solve this problem first before we go back to the routing issue using the VPN.
[....]
>>One other thing... unless you run into other issues and really need "proto tcp" to keep a session open to keep the openvpn traffic flowing, the preferred proto for the openvpn traffic itself is udp. >The reason for that is that when sending tcp traffic inside a tunnel that is using the tcp mechanism to resend packets when needed, things can really go wrong in some cases.
>>Do not change it just now, lets first solve your current problem but... once that is solved see if still you have a working openvpn tunnel if you switch to udp. In most cases you get a better >throughput. In some isolated cases the performance is better using tcp, just see what is better for you.
>
>I am using the vpn config the company gave me to use. I just customized it to store my vpn password in a file, rather than enter it manually. But I'll try udp, I take a performance hit, but I assumed >that was entirely due to the extra routing hops to their network. Maybe it will give me some of that performance hit back. Thanks.
No, do not change it then. If the server side says you need to use proto tcp then that is what YOU need to use too.
Bonno Bloksma
Reply to: