Hello, I'm looking for an effective way to estabilish a VPN between Openwrt and Paloalto firewall. I tryed VPNC but got stuck with some performance issues so I started looking for another solution. I installed Strongswan, followed the tutorial provided by paloalto. That sort of worked, VPN was estabilshed and I can even SSH to openwrt using the internal IP given by paloalto. The problem is that I can't eve ping the router (openwrt) from the lan side of openwrtand not even ping anything from Openwrt itself. I wanted all the traffic from clients to be forwarded to the tunnel. Can I even achieve that using strongswan client-to-site?
Did you create a route to send traffic over the tunnel?
Not sure what you mean. As far as I understand strongswan/ipsec should create routes based on ipsec.conf. I'm still reading their documentation but as far as I understand the following should be enough:
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 0 0 0 eth2
192.168.0.0 * 255.255.255.0 U 0 0 0 eth2
192.168.0.1 * 255.255.255.255 UH 0 0 0 eth2
192.168.123.0 * 255.255.255.0 U 0 0 0 br-lan
root@OPENWRT-LAB:~#
root@OPENWRT-LAB:~# ip route list table 220
default via 192.168.0.1 dev eth2 proto static src 10.103.0.123
Here 10.103.0.123 is defined by paloalto when the session is estabilished, eth2 is wan, 192.168.0.1 is the modem.
According to Strongswan:
Routing
On Linux, strongSwan installs routes into routing table 220 by default and hence requires the kernel to support policy
based routing.
You can make the daemon install the routes into any table you like, or you can disable it completely.
For those purposes, the charon.install_routes, charon.routing_table and charon.routing_table_prio settings
in strongswan.conf may be used. When a tunnel is established between two subnets, charon tries to find local IPs in the tunneled
local subnets. Such an IP must be configurd with scope global to be viable for the lookup. If a valid IP is found, charon will install
a route pointing to the remote subnet where the source IP is set to the found IP. This results in routes like the following:
10.1.0.0/24 via 10.2.0.1 src 10.2.0.2
In that example, the local IP would be 10.2.0.2. The remote subnet would be 10.1.0.0/24.
This is done so packets to the remote subnet are sent with the correct source IP, so the IPsec policies match and traffic
from the local machine to the remote subnet will be secured with IPsec.