Hello, I''m having troubles with a DNAT rule to forward traffic (in this case TCP port 80) across an OpenVPN tunnel. I believe the problem might be routing but I''m not quite sure - I hope i''m giving enough detail. My Setup: Server (Linux - Shorewall, OpenVPN) External IP: 216.223.xxx.12 (eth0) OpenVPN Server: 172.20.15.1 (tun0) Client (Linux - Shorewall, OpenVPN) External IP: 152.222.xxx.91 (eth0) OpenVPN (client IP): 172.20.15.6 (tun1) Local IP (firewall internal interface):10.1.1.1 (eth1) What works: - The client connects to the server and using the iroute directive in OpenVPN, if I SSH to the server I can ''reach'' any clients on the subnet of the client. EX: I can ping workstations on the 10.1.1.0/24 network, or RDP. - I can ''reach'' the server from the local subnet - traffic in both directions works as expected - Shorewall is configured as expected and everything works except the port forwarding rule described below What doesn''t work: - packets seem to be dropped to a server on the client subnet (server IP: 10.1.1.99) when I use a DNAT rule to port forward TCP port 80 traffic. I should be clear that when I implement the following DNAT rule packets reach the destination (10.1.1.99) - I can see them using the debug or info LOG directives in shorewall. I suppose it sort of ''half works''. However, when I run netstat -na on that server, I see multiple SYN_RECV entries and none which are ESTABLISHED. Eventually the connection fails/times out (I am testing externally as I''m clear that this cannot be tested on an internal system): ON the Server: (rule) DNATnetvpn:10.1.1.99tcp 80 -216.223.xxx.12 To dig a bit deeper I ran TCPDUMP on 10.1.1.99 and opened the results in Wireshark to see what was happening. It appears that packets reach the server, but are either dropped (without a SYN-ACK) or are going out the gateway of the client (152.222.xxx.91) instead of traversing the vpn tunnel back to the server and out that gateway. I''m not sure of that last sentence, but I think the latter of the two is correct. I have deployed Mr. Eastep''s suggestion for split internal/external DNS so clients can reach the destination server from the local subnet. Everything is working as expected except for this translation across the VPN. I hope I''ve given enough information - it''s the first time I''ve asked a question; I also hope the format in which I''ve asked is sufficent. Thank you kindly for your time. Mike ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 06/28/2012 08:34 PM, Michael Johannes wrote:> My Setup: > > Server (Linux - Shorewall, OpenVPN) External IP: 216.223.xxx.12 > (eth0) OpenVPN Server: 172.20.15.1 (tun0) > > Client (Linux - Shorewall, OpenVPN) > > External IP: 152.222.xxx.91 (eth0) OpenVPN (client IP): 172.20.15.6 > (tun1) Local IP (firewall internal interface):10.1.1.1 (eth1)> What doesn''t work: - packets seem to be dropped to a server on the > client subnet (server IP: 10.1.1.99) when I use a DNAT rule to port > forward TCP port 80 traffic. > > I should be clear that when I implement the following DNAT rule > packets reach the destination (10.1.1.99) - I can see them using the > debug or info LOG directives in shorewall. I suppose it sort of ''half > works''. However, when I run netstat -na on that server, I see > multiple SYN_RECV entries and none which are ESTABLISHED. Eventually > the connection fails/times out (I am testing externally as I''m clear > that this cannot be tested on an internal system): > > ON the Server: (rule) > > DNAT net vpn:10.1.1.99 tcp 80 - 216.223.xxx.12 > > To dig a bit deeper I ran TCPDUMP on 10.1.1.99 and opened the results > in Wireshark to see what was happening. It appears that packets reach > the server, but are either dropped (without a SYN-ACK) or are going > out the gateway of the client (152.222.xxx.91) instead of traversing > the vpn tunnel back to the server and out that gateway. I''m not sure > of that last sentence, but I think the latter of the two is correct.Yes -- that''s exactly what is happening.> I hope I''ve given enough information - it''s the first time I''ve asked > a question; I also hope the format in which I''ve asked is sufficent.The cheap way to fix this is to SNAT traffic out of tun0 on the server, but that approach has the drawback that all connections forwarded via the DNAT rule appear to come from the 172.20.15.0 subnet. A more complete solution is to use a Multi-ISP setup on the client where eth0 is a ''balance'' provider and tun0 is an optional ''fallback'' provider. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Thank you for the quick reply, much appreciated. I''m interested in doing this properly by deploying the balanced multi-isp config you''ve suggested but am also hoping to have the cheap fix implemented with the understanding it''s only temporary. To implement SNAT on the server i''ve added an entry to my /etc/shorewall/masq file that looks like this: (vpn) (ext) (external IP) tun0 eth0 216.223.xxx.12 tcp www After restarting shorewall I tried loading the page but the results were the same (SYN_RECV but no response back to the server from the client server). I thought maybe I had the masq entry backwards so i tried eth0 to tun0 but that didn''t work either. Have I attempted an over-simplified solution by only adding one entry to my masq file? I don''t think this is supposed to be a defined SNAT rule in /etc/shorewall/rules - I think masq is what I''m looking for. I''m wondering if there is anything else I should add on the client side? Thanks again for your time. Mike ----- Original Message ----- From: Tom Eastep <teastep@shorewall.net> To: shorewall-users@lists.sourceforge.net Cc: Sent: Friday, 29 June 2012, 10:56 Subject: Re: [Shorewall-users] Question regarding DNAT across a VPN Tunnel On 06/28/2012 08:34 PM, Michael Johannes wrote:> My Setup: > > Server (Linux - Shorewall, OpenVPN) External IP: 216.223.xxx.12 > (eth0) OpenVPN Server: 172.20.15.1 (tun0) > > Client (Linux - Shorewall, OpenVPN) > > External IP: 152.222.xxx.91 (eth0) OpenVPN (client IP): 172.20.15.6 > (tun1) Local IP (firewall internal interface):10.1.1.1 (eth1)> What doesn''t work: - packets seem to be dropped to a server on the > client subnet (server IP: 10.1.1.99) when I use a DNAT rule to port > forward TCP port 80 traffic. > > I should be clear that when I implement the following DNAT rule > packets reach the destination (10.1.1.99) - I can see them using the > debug or info LOG directives in shorewall. I suppose it sort of ''half > works''. However, when I run netstat -na on that server, I see > multiple SYN_RECV entries and none which are ESTABLISHED. Eventually > the connection fails/times out (I am testing externally as I''m clear > that this cannot be tested on an internal system): > > ON the Server: (rule) > > DNAT net vpn:10.1.1.99 tcp 80 - 216.223.xxx.12 > > To dig a bit deeper I ran TCPDUMP on 10.1.1.99 and opened the results > in Wireshark to see what was happening. It appears that packets reach > the server, but are either dropped (without a SYN-ACK) or are going > out the gateway of the client (152.222.xxx.91) instead of traversing > the vpn tunnel back to the server and out that gateway. I''m not sure > of that last sentence, but I think the latter of the two is correct.Yes -- that''s exactly what is happening.> I hope I''ve given enough information - it''s the first time I''ve asked > a question; I also hope the format in which I''ve asked is sufficent.The cheap way to fix this is to SNAT traffic out of tun0 on the server, but that approach has the drawback that all connections forwarded via the DNAT rule appear to come from the 172.20.15.0 subnet. A more complete solution is to use a Multi-ISP setup on the client where eth0 is a ''balance'' provider and tun0 is an optional ''fallback'' provider. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 06/29/2012 09:03 AM, Michael Johannes wrote:> Thank you for the quick reply, much appreciated. > > I''m interested in doing this properly by deploying the balanced > multi-isp config you''ve suggested but am also hoping to have the > cheap fix implemented with the understanding it''s only temporary. > > To implement SNAT on the server i''ve added an entry to my > /etc/shorewall/masq file that looks like this: > > (vpn) (ext) (external IP) tun0 eth0 216.223.xxx.12 > tcp wwwtun0 - 172.20.15.1 tcp www -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Works perfectly, thank you very much. Mike ----- Original Message ----- From: Tom Eastep <teastep@shorewall.net> To: shorewall-users@lists.sourceforge.net Cc: Sent: Friday, 29 June 2012, 14:12 Subject: Re: [Shorewall-users] Question regarding DNAT across a VPN Tunnel On 06/29/2012 09:03 AM, Michael Johannes wrote:> Thank you for the quick reply, much appreciated. > > I''m interested in doing this properly by deploying the balanced > multi-isp config you''ve suggested but am also hoping to have the > cheap fix implemented with the understanding it''s only temporary. > > To implement SNAT on the server i''ve added an entry to my > /etc/shorewall/masq file that looks like this: > > (vpn) (ext) (external IP) tun0 eth0 216.223.xxx.12 > tcp wwwtun0 - 172.20.15.1 tcp www -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/