Problem on Routing/IP_Forwarding

[Island108]

Hello,

We have installed OpenVPN on our new server and we want to use the server as gateway to Internet. Openvpn client can now connect successfully to the VPN server but we have a problem with routing and/or ip_forwarding. Packet forwarding from the VPN interface (tun0) to the WAN interface (eth1) is not working.

We have enable routing:
echo 1 > /proc/sys/net/ipv4/ip_forward


..and setup the required address translation through iptables:
iptables -t nat -A POSTROUTING -s 0/0 -d 0/0 -j SNAT --to-source <public IP of the server>

We have this same setup on another box and everything is working so I don't think it's a problem on our configuration.

Is there a restriction on your server that is causing ip_forwarding to fail?

[Edge100x]

We don't have anything that would prevent any software from running here. Our unmanaged VDSes and dedicated machines provide you with full root access, and you could even reinstall the OS from scratch if you wanted to. If you are experiencing a software issue, it would have to be in the custom configuration you have loaded or in the OS itself.

Are you sure that you don't need a "-o" or "-i" specification in that iptables rule (or a valid "-s" specification)? This one would NAT all interfaces, I believe, which probably isn't what you want.

Are you certain that the adapter is eth1 and not eth0?

I'm not very familiar with OpenVPN, but if you're looking to use this machine to use the internet remotely, have you tried the simpler SOCKS proxy solution via Putty or another SSH client?

[Island108]

Hello,

I already reinstalled the OS but I still get the same problem. IP_forwarding is not working. I already made so many modifications with the iptables rules but I cannot get it to work on your server. I have the same machine with the same exact configuration and ip_forwarding works there.

We want to use VPN so that users don't have to use any socks client.

Thanks.

[Edge100x]

Again, a VDS would use "eth0" as the network adapter and not "eth1". Have you adjusted your scripts for this? You would need to do so.

[Island108]

This is what I see on our VDS server:

[root@evershawn ~]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:16:3E:56:72:D9

...but I will change it to eth0 and see if that helps.

Thanks,

Rommel

[Island108]

I already changed it to eth0 but it is still not working.

[root@evershawn ipv4]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:16:3E:56:72:D9

I was also informed that there is a default VPN setup on the server initially (when the OS is first installed). Is this true? How can I access/use that?

Thanks.

[Island108]

I forgot to add:

I already fixed the firewall too to make use of eth0.

Thanks.

[Edge100x]

I was also informed that there is a default VPN setup on the server initially (when the OS is first installed). Is this true? How can I access/use that?

I'm not aware of one, but there might be a role that you can install for your particular OS choice.

[paulg1981]

I know this is an old thread but I am having the exact same problem. I have finished migrating from my old server and this is the one thing that is tripping me up is the openvpn setup. Both servers are Ubuntu 10.04 LTS and the configs are identical.

I can successfully connect to the openvpn server but nothing is routed (intranet or internet). I have enabled ip forwarding and the iptables rules are identical. I have no issue with the old server it has been used as a vpn for months.

I have been working on this one issue for over a day now and I am running out of ideas? This has to be a VPN specific issue. Please help me complete my migration.

Paul

[paulg1981]

Here are the configs with my ips removed:

Server.conf:
server 10.8.0.0 255.255.255.0
local second.vps.ip
dev tun
proto udp
comp-lzo
tun-mtu 1500
push "redirect-gateway def1"
push "dhcp-option DNS 208.67.222.222"
keepalive 10 60
dh dh1024.pem
ca ca.crt
cert server.crt
key server.key
user openvpn
group openvpn
persist-key
persist-tun
mute-replay-warnings
status openvpn-status.log

UFW before.rules:


#
# rules.before
#
# Rules that should be run before the ufw command line added rules. Custom
# rules should be added to one of these chains:
# ufw-before-input
# ufw-before-output
# ufw-before-forward
#

# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines


# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT

# quickly process packets for which we already have a connection
-A ufw-before-input -m state --state RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -m state --state RELATED,ESTABLISHED -j ACCEPT

# drop INVALID packets (logs these in loglevel medium and higher)
-A ufw-before-input -m state --state INVALID -j ufw-logging-deny
-A ufw-before-input -m state --state INVALID -j DROP

# ok icmp codes
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-input -p icmp --icmp-type source-quench -j ACCEPT
-A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT

# allow dhcp client to work
-A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT

#
# ufw-not-local
#
-A ufw-before-input -j ufw-not-local

# if LOCAL, RETURN
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN

# if MULTICAST, RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN

# if BROADCAST, RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN

# all other non-local packets are dropped
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP

# allow MULTICAST, be sure the MULTICAST line above is uncommented
-A ufw-before-input -s 224.0.0.0/4 -j ACCEPT
-A ufw-before-input -d 224.0.0.0/4 -j ACCEPT

# allow all traffic via our OpenVPN interface
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT

COMMIT
*nat

OSTROUTING ACCEPT [0:0]

-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to first.vps.ip
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to second.vps.ip

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

I have also made sure to include net.ipv4.ip_forward=1 in /etc/sysctl.conf and /etc/ufw/sysctl.conf


PLEASE HELP ME SOLVE THIS ISSUE!

[Edge100x]

The other customer changed his scripts and fixed his configuration after his post, IIRC, but he did not tell me what he needed to do.

iptables rules would not work properly if they were IP-specific/adapter-specific/MAC-specific, so you might take a look at them to see if they were customized. Have you also tried the latest release of both the OS (12.04-LTS) and OpenVPN?

[paulg1981]

Quick response as always

I actually had the same issue with 12.04 and decided to revert to 10.04 to match the server i had humming along. I encountered higher loads with 12.04 as well but I digress.

I will take out the interface options in the firewall and give it a try, thanks for the suggestion.

[Edge100x]

I see that you're also using UDP there. Is there a chance that the client is misconfigured and sending too-large UDP packets that are being fragmented? If so, these would be filtered before reaching the VDS, as UDP fragments are a very common DDoS attack vector.

[paulg1981]

I am using the same client configuration so I don't think so. I am at a loss for how to modify my iptables/ufw rules and not make them ip specific or adapter specific? Any help would be appreciated. the only rules I have modified are:

-A INPUT -i tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to first.vps.ip
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to second.vps.ip

Would I just remove the source and adapter statements like this?

-A INPUT -j ACCEPT
-A FORWARD -j ACCEPT
-A POSTROUTING -j SNAT --to first.vps.ip
-A POSTROUTING -j SNAT --to second.vps.ip

I will also try switching to tcp to see if it makes any difference.

EDIT: Tried switching to tcp with the same results, looks like a iptables problem....

[paulg1981]

Can you expound on the differences there should be for the iptables rules for a vps rather than a dedicated? I have a feeling this is the issue as you described above?