On 7/30/12 6:25 AM, Bas van Schaik wrote: > Hi all, > > I've been struggling with a rather exotic routing challenge for a few > days now, hope someone here can give me some hints. I'm running a > virtualised server (Debian, Shorewall 4.5.5.3, IP > 123.123.123.123/255.255.255.0 - let's call this 'server') in on a > location at which all ports except for 22 are firewalled. I need access > to this server on ports 25, 143, 587, 80, and 443, so I decided to hire > a VPS (Debian, Shorewall 4.4.11, IP 234.234.234.234/255.255.255.0) - > let's call this 'vps-gateway') which runs OpenVPN. The server connects > to the vps-gateway, and Shorewall on the vps-gateway is configured to > DNAT the ports mentioned above to the server. A shorewall dump of the > server is attached (vps-gateway is irrelevant, that one works fine), > which will show you a set-up using two providers: > - prov_main: main outgoing network connection (over LAN with gateway) > - prov_vpn: provider created for traffic coming in through the > vps-gateway (with 'track' option) > > This works beautifully: traffic coming in on 234.234.234.234 gets > DNATted to 192.168.103.6 (IP of server on VPN), is sent to the server, > and the server routes replies back using tun0 via vps-gateway through > the prov_vpn provider. Even though the default gateway for the server is > 123.123.123.254 on eth0 (123.123.123.123/255.255.255.0). So the routing > responses over the same interface works. > > One problematic exception: traffic from the server's LAN (e.g. a client > at 123.123.123.100/255.255.255.0) with destination 234.234.234.234. The > packets get DNATted at the vps-gateway and sent to the server through > the VPN (as is to be expected), but the server acts in one of three ways > (seemingly at random, not sure what's going on here): > - mark this packet with source address 123.123.123.100 on the tun0 > (VPN) interface as martian (as it would normally route these packets > through eth0) and ignore it: > Jul 30 13:44:33 server kernel: [240307.716218] martian source > 192.168.103.6 from 123.123.123.100, on dev tun0 > - ignore the packets, no martian log > - process the packets, but ignore the track/routeback and route packets > using prov_main with source 192.168.103.6 and destination > 123.123.123.100 which was expecting packets from 234.234.234.234) > > I've seen all three types of behaviour. As the shorewall dump shows, > ROUTE_FILTER=No in shorewall.conf. To summarise, this is what happens: > > 123.123.123.100 => 234.234.234.234 port 143 > DNAT at vps-gateway: 123.123.123.100 => 192.168.103.6 (via tun0, > prov_vpn) > 192.168.103.6 => 123.123.123.100 (eth0, prov_main) --- WRONG! > > What I'd like to see (and what works for any other packet with source > outside 123.123.123.0/255.255.255.0): > > 123.123.123.100 => 234.234.234.234 port 143 > DNAT at vps-gateway: 123.123.123.100 => 192.168.103.6 (via tun0, > prov_vpn) > 192.168.103.6 => 123.123.123.100 (via tun0, prov_vpn) --- RIGHT! > SNAT at vps-gateway: 234.234.234.234 => 123.123.123.100 > > > It seems that the routeback/track settings on the interface and > providers does not have priority over the default routing of packets in > the local 123.123.123.0/255.255.255.0 network? But maybe I'm wrong. Note > that I don't have control over routing tables or DNS in the > 123.123.123.0/255.255.255.0 subnet - the machines in that subnet rely on > regular DNS to resolve the IP of my server (234.234.234.234) and I > really need those machines to be able to connect to my server using this > detour via the vps-gateway at 234.234.234.234. > > Hopefully, someone can shed some light on this. Thanks!
You are going to have to shed some light first. You have sent us a dump with what appear to be the actual IP addresses, yet your description of the problem doesn't use those IP addresses. This kind of problem always comes down to details; we can't help you if we don't have those details. Please describe your problem using the actual addresses and we'll try to help. Thanks, -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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
