Hi again, sorry, but I'm still having issues with my setup as described in my previous posts (multi-isp setup with openvpn and dsl router). The problem is that if I try to connect from LAN (192.168.5.181) to the VPN ip (x.x.x.245) via a DNAT rule, the request gets forwarded, but the reply doesn't obviously find the way back. In detail, the request is on port 993 and is being forwarded from the openvpn ip x.x.x.245 on device tun1 to the internal ip 192.168.5.4. The rule forwarding the request is the following one: DNAT lan lan:192.168.5.4:993 tcp 993 - x.x.x.245 The tcpdump on the target system for port 993: IP (tos 0x0, ttl 63, id 25228, offset 0, flags [DF], proto: TCP (6), length: 64) 192.168.5.181.51933 > 192.168.5.4.993: S, cksum 0x8288 (correct), 3501222380:3501222380(0) win 65535 <mss 1460,nop,wscale 4,nop,nop,timestamp 564067697 0,sackOK,eol> IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) 192.168.5.4.993 > 192.168.5.181.51933: S, cksum 0x1921 (correct), 3752783027:3752783027(0) ack 3501222381 win 5792 <mss 1460,sackOK,timestamp 45978776 564067697,nop,wscale 7> IP (tos 0x0, ttl 64, id 56928, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.5.181.51933 > 192.168.5.4.993: R, cksum 0x1a7a (correct), 3501222381:3501222381(0) win 0 The request finds it's way to 192.168.5.4, because I've used the option routeback on the interface eth2. All the hosts in 192.168.5.0/24 have 192.168.5.251 as a gateway, which is eth2 under shorewall. The providers file: tonline 1 1 - eth1 192.168.2.1 track ipev 2 2 - tun1 x.x.x.245 track The rtrules file: #SOURCE DEST PROVIDER PRIORITY MARK - x.x.x.18/32 tonline 1000 - x.x.x.245/28 ipev 1001 192.168.0.0/24 - tonline 20001 1 192.168.5.0/24 - tonline 20001 1 192.168.0.0/24 - tonline 20002 192.168.5.0/24 - tonline 20002 zones: fw firewall lan ipv4 wan ipv4 vpn ipv4 dmz ipv4 So long story short: the communication from lan to lan:192.168.5.4:993 is working forward, but does not make it's way back. Coming from outside on the tun1 (x.x.x.245) is fine - the request get's forwarded and the reply finds it's way back to the originator of the communication. Have you got any clue about how I can establish the way back? Thank you! Regards Michael PS: I could use 192.168.5.4 instead x.x.x.245 but that's a bit difficult on a smartphone where I cannot really use LAN addresses. ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce