asked on

How to get iptables to forward ports from a OpenVPN client tunnel on Red Hat 5.5?

I have a Red Hat 5.5 server running as a firewall using iptables. I need to move from a fixed public IP address to a VPN tunnel over OpenVPN.

The firewall (iptables) worked perfectly with the fixed IP address, but when I moved to the OpenVPN it no longer forwards the requests. I can SSH to the firewall server through the VPN tunnel, so I know the VPN is working and connected. In the iptables I have forwarded port 80 to an internal server, but when I try to access this through the OpenVPN tunnel it will not forwarded the request like it did when it was configured with the fixed address.

Do have have to do something special in the OpenVPN client file to get iptables to work? Is there something I am missing?

Attached are my OpenVPN config files and iptables configuration. (The addresses and account info are chanced for my protection.)

Thanks. firewall-rules.sh client.conf.txt firewall-rules.sh firewall-rules.sh

akevinbailey

ASKER

Please ignore the last two "firewall-rules.sh" attachements.

Duncan Roe

Please post output from ifconfig -a

akevinbailey

ASKER

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:935 errors:0 dropped:0 overruns:0 frame:0
TX packets:935 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1733064 (1.6 MiB) TX bytes:1733064 (1.6 MiB)

seth0 Link encap:Ethernet HWaddr 00:15:5D:64:05:25
inet addr:10.53.201.87 Bcast:10.53.201.127 Mask:255.255.255.192
inet6 addr: fe80::215:5dff:fe64:525/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:42041 errors:0 dropped:0 overruns:0 frame:0
TX packets:31999 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:29539718 (28.1 MiB) TX bytes:4328112 (4.1 MiB)

seth1 Link encap:Ethernet HWaddr 00:15:5D:64:05:26
inet addr:10.100.100.4 Bcast:10.100.100.255 Mask:255.255.255.0
inet6 addr: fe80::215:5dff:fe64:526/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:290773 errors:0 dropped:0 overruns:0 frame:0
TX packets:1387 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:38098092 (36.3 MiB) TX bytes:830050 (810.5 KiB)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.80.70.202 P-t-P:10.80.70.202 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:457 errors:0 dropped:0 overruns:0 frame:0
TX packets:556 errors:0 dropped:71348 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:132566 (129.4 KiB) TX bytes:63197 (61.7 KiB)

Duncan Roe

The really unusual feature in your ifconfig is that both ends of the point to point tunnel have the same IP address. In every ppp implementation I have seen previously, they have been different, so I would say having them the same is not normal. Possibly it is not in fact the case - can you verify at the remote end that the address there of the tun interface is in fact 10.80.70.202 there? It might not be a problem even so, it's just that I've never seen it before.
Separately, does the command tcpdump -i tun0 tcp and port 80 show packets going in both directions? tcpdump does see incoming frames that iptables subsequently filters out - I don't see a filter rule to allow them in. You have

iptables -A INPUT -p all -i lo -s 10.80.70.202 -j ACCEPT

Open in new window

But I would have put

iptables -A INPUT -p all -i tun0 -s 10.80.70.202 -j ACCEPT

Open in new window

or maybe miss out the -i option altogether.
If problems persist, please also post the output from ip route list

Duncan Roe

(The addresses and account info are chanced for my protection.)
Don't do this with addresses please, except possibly for real actual external addresses (not networks 10 or 192.168). Otherwise you just waste your time and mine

akevinbailey

ASKER

I tried "tcpdump -i tun0 tcp and port 80" and also "tcpdump -i seth1 tcp and port 80". I see the HTTP request on both interfaces, but the request is not being sent out on seth1.

Duncan Roe

Please post output from ip route list
Did you try the change to iptables -A INPUT that I suggested? Note that you need to mention the address of the other end of the PtP connection in this rule.
Please indicate which addresses I can trust and which are mangled.
How do you know the request is not being sent out on seth1?

akevinbailey

ASKER

I tried the iptables -A INPUT changes, it didn't work.

I have a network packet sniffer on the switch.
Here is the output for ip rout list. I put in the address 46.19.01.10 is not the real IP address. I don't want to reveal the real address over an open forum.
> ip rout list
46.19.01.10 via 10.53.201.65 dev seth0
10.53.201.64/26 dev seth0 proto kernel scope link src 10.53.201.87
10.80.70.0/24 via 10.80.70.1 dev tun0
10.80.70.0/24 dev tun0 proto kernel scope link src 10.80.70.202
10.100.100.0/24 dev seth1 proto kernel scope link src 10.100.100.4
169.254.0.0/16 dev seth1 scope link
0.0.0.0/1 via 10.80.70.1 dev tun0
128.0.0.0/1 via 10.80.70.1 dev tun0
default via 10.53.201.65 dev seth0

Duncan Roe

Thanks for posting that.
I wonder whether you should expect to see tunneled TCP requests with a sniffer on the switch - wouldn't they be totally encrypted as data packets on an established VPN connection?
One of seth0 and tun0 will be intended for the exclusive use of the tunneling process - is that tun0? It looks to me like seth0 is the interface for packets to be encrypted, since it is the default route. In that case you should probably be allowing any packets from tun0 to go on the input chain - it's a "trusted" interface since the other end is only used by the remote VPN process. Then you need to allow some packets off seth0 onto the input chain as well. Personally I've only done this sort of thing for PPTP rather than OpenVPN because there was a Windoze box at the other end. That was a little time ago - I'll re-check what I did there (it's at work).

ASKER CERTIFIED SOLUTION

akevinbailey

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Duncan Roe

Well I got you looking, didn't I? Not impressed with your decision to close, but I won't object.

akevinbailey

ASKER

I found the answer.