• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 654
  • Last Modified:

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
0
akevinbailey
Asked:
akevinbailey
  • 6
  • 6
1 Solution
 
akevinbaileyAuthor Commented:
Please ignore the last two "firewall-rules.sh" attachements.
0
 
Duncan RoeSoftware DeveloperCommented:
Please post output from ifconfig -a
0
 
akevinbaileyAuthor 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)

0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
Duncan RoeSoftware DeveloperCommented:
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
0
 
Duncan RoeSoftware DeveloperCommented:
(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
0
 
akevinbaileyAuthor 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.
0
 
Duncan RoeSoftware DeveloperCommented:
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?
0
 
akevinbaileyAuthor 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
0
 
Duncan RoeSoftware DeveloperCommented:
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).
0
 
akevinbaileyAuthor Commented:
I got it to work I need to change the SNAT to the local address (10.100.100.4)

I changed iptables -t nat -A POSTROUTING -o tun0 -j SNAT -- to 10.80.70.202
to: iptables -t nat -A POSTROUTING -o seth1 -j SNAT -- to 10.100.100.4

Now everything is working!
0
 
Duncan RoeSoftware DeveloperCommented:
Well I got you looking, didn't I? Not impressed with your decision to close, but I won't object.
0
 
akevinbaileyAuthor Commented:
I found the answer.
0

Featured Post

Upgrade your Question Security!

Add Premium security features to your question to ensure its privacy or anonymity. Learn more about your ability to control Question Security today.

  • 6
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now