We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now

x

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

Medium Priority
682 Views
Last Modified: 2013-12-06
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
Comment
Watch Question

Author

Commented:
Please ignore the last two "firewall-rules.sh" attachements.
Duncan RoeSoftware Developer
CERTIFIED EXPERT

Commented:
Please post output from ifconfig -a

Author

Commented:
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 RoeSoftware Developer
CERTIFIED EXPERT

Commented:
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 RoeSoftware Developer
CERTIFIED EXPERT

Commented:
(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

Author

Commented:
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 RoeSoftware Developer
CERTIFIED EXPERT

Commented:
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?

Author

Commented:
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 RoeSoftware Developer
CERTIFIED EXPERT

Commented:
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).
Unlock this solution with a free trial preview.
(No credit card required)
Get Preview
Duncan RoeSoftware Developer
CERTIFIED EXPERT

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

Author

Commented:
I found the answer.
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a free trial preview!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.