On 7/30/12 7:24 AM, Bas van Schaik wrote: > Hi Tom, > > On 30/07/12 15:11, Tom Eastep wrote: >> Please describe your problem using the actual addresses and we'll try >> to help. Thanks, -Tom > OK, here it goes: > > > 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 > 129.67.194.105/255.255.252.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 37.34.58.203 - let's call this > 'vps-gateway') which runs OpenVPN. Note that I can't actually move the > server into a VPS provider for some practical reasons. > > 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 37.34.58.203 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 > 129.67.195.254 on eth0. So the routing responses over the same interface > works. > > One problematic exception: traffic from the server's own eth0 subnet > (e.g. a client at 129.67.194.100) with destination 37.34.58.203. 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 129.67.194.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 129.67.194.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 129.67.194.100 > which was expecting packets from 37.34.58.203) > > 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: > > 129.67.194.100 => 37.34.58.203 port 143 > DNAT at vps-gateway: 129.67.194.100 => 192.168.103.6 (via tun0, prov_vpn) > reply: 192.168.103.6 => 129.67.194.100 (eth0, prov_main) --- WRONG! > > What I'd like to see (and what works for any other packet with source > outside 129.67.194.0/255.255.252.0): > > 129.67.194.100 => 37.34.58.203 port 143 > DNAT at vps-gateway: 129.67.194.100 => 192.168.103.6 (via tun0, prov_vpn) > reply: 192.168.103.6 => 129.67.194.100 (via tun0, prov_vpn) --- RIGHT! > SNAT at vps-gateway: 37.34.58.203 => 129.67.194.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 129.67.194.0/255.255.252.0 network? But maybe I'm wrong. Note > that I don't have control over routing tables or DNS in the > 129.67.194.0/255.255.252.0 subnet - the machines in that subnet rely on > regular DNS to resolve the IP of my vps-gateway (37.34.58.20) and I > really need those machines to be able to connect to my server using this > detour via the vps-gateway at 37.34.58.20. > > Hopefully, someone can shed some light on this. Thanks!
From the Dump: Table prov_main: 192.168.103.5 dev tun0 scope link src 192.168.103.6 129.67.195.254 dev eth0 scope link src 129.67.194.105 80.239.201.0/24 via 192.168.103.5 dev tun0 64.238.147.0/24 via 192.168.103.5 dev tun0 213.155.154.0/24 via 192.168.103.5 dev tun0 208.99.166.0/24 via 192.168.103.5 dev tun0 199.222.69.0/24 via 192.168.103.5 dev tun0 192.168.103.0/24 via 192.168.103.5 dev tun0 129.67.192.0/22 dev eth0 proto kernel scope link src 129.67.194.105 default via 129.67.195.254 dev eth0 src 129.67.194.105 Table prov_vpn: 192.168.103.5 dev tun0 scope link src 192.168.103.6 129.67.195.254 dev eth0 scope link src 129.67.194.105 80.239.201.0/24 via 192.168.103.5 dev tun0 64.238.147.0/24 via 192.168.103.5 dev tun0 213.155.154.0/24 via 192.168.103.5 dev tun0 208.99.166.0/24 via 192.168.103.5 dev tun0 199.222.69.0/24 via 192.168.103.5 dev tun0 192.168.103.0/24 via 192.168.103.5 dev tun0 129.67.192.0/22 dev eth0 proto kernel scope link src 129.67.194.105 <=== default via 192.168.103.5 dev tun0 src 192.168.103.6 Looks to me like your COPY column contents in /etc/shorewall/providers are wrong. The routes out of eth0 are copied into the VPN's routing table; see the entry marked <=== above. -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
