[SOLVED]: Route some traffic over site B gateway

[razer0r]

Hi,

I've successfully created a link between my virtualised pfSense firewall in Germany and my home router (dd-wrt) using a seperate openvpn config. Germany = Site A, home = Site B

Networks:
WAN Site A: 1.2.3.4
WAN Site B: 4.3.2.1
LAN Site A: 192.168.60.0/24
LAN Site B: 192.168.22.0/24

Third party ip: 2.2.2.2

Openvpn tunnel using: 10.0.148.0/24 (Site A is using 10.0.148.1 and Site B is using 10.0.148.2)

Both private lans are able to talk to each other :-).

on a second openvpn config I am connecting from Denmark (lots of country's, I know ;-) ).
It's a cert based config using 10.0.1.0/24 as range. All traffic is routed through the Site A gateway (bypassing firewalls and stuff), which seems to work perfectly.

I added the following iptables rule on Site B to allow traffic from 10.0.1.0 to LAN site B

route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.0.148.1

and pings from 10.0.1.x to 192.168.22.x are flowing like a charm.

Now I want to achieve the following:

route some traffic from 10.0.1.0 through the gateway of Site B. (2.2.2.2 only allows traffic from the ip 4.3.2.1. At the moment all traffic from 10.0.1.x leaves through 1.2.3.4…

I already found out that by adding 2.2.2.2/31 to the "IPv4 Remote Network/s" the traffic get's routed to 10.0.148.2 so traffic arrives at my DD-WRT router...

But it seems to block there...

Anyone any suggestions?

[phil.davis]

In principle, the DD-WRT home router (site B) has to:

1. Allow incoming packets on the OpenVPN link from site A addresses (at least including 10.0.1.0/24) too 2.2.2.2 (or as big a range of destination IPs as you like)
2. NAT those packets out on WAN (it should already route them out WAN by default, since the destination 2.2.2.2 is an ordinary public IP)

The NAT is necessary, otherwise the source IP will not be the home router (site B) and so reply traffic will not come back.

Not being a DD-WRT guy, I leave it up to you or others as to how to implement the above.

[razer0r]

Thank you so much, the final piece of the puzzle has been found ;-)

The NAT table was something i completely forgot to check ;-).

Rules that made my day:

iptables -I FORWARD -i tun0 -o vlan2 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -o vlan2 -j SNAT --to-source $(nvram get wan_ipaddr)

The first one to allow packets from the tunnel to go to the wan interface and the second to activate the natting for those packets ;-)