[strongSwan] Problem when forwarding all traffic to tunnel (site-to-site VPN)

[Tom Rymes]

If nothing else, you can use the updown script to add these entries, I presume?

> On Sep 21, 2015, at 3:41 AM, Rajiv Kulkarni <rajivkulkarni69 at gmail.com> wrote:
> 
> Hi
> Thats great. Yes ofcourse...addition and deletion/updation of new networks of lan in to this strongawan routing table 220 has to be done dynamically ...i dont know how at this time
> 
> -rajiv
> 
> 
>> On Mon, Sep 21, 2015 at 9:18 AM, Rayson Zhu <vfreex at gmail.com> wrote:
>> Hi Rajiv,
>> Thanks.for your reply. I tried your method and now my LAN is able to access to the Internet. But dealing with routes by manual is troublesome when a gateway already had complex routing tables. I will use this workaround temporarily and continue to find other solutions. 
>> 
>>> On Sun, Sep 20, 2015 at 11:39 PM, Rajiv Kulkarni <rajivkulkarni69 at gmail.com> wrote:
>>> Hi
>>> 
>>> One workaround method i have been using in this scenario is to put the route you have added into table 220 - the routing table referenced by strongswan.
>>> e,g:
>>> 
>>> ip route add 10.10.0.0/16 dev lan table 220
>>> 
>>> - i guess it should start working with the above route in table 220
>>> - the route you have added (without table 220) is included in the main routing table, which is correct, but is not referenced by strongswan
>>> - this is a issue on a GW/peer, especially and only, when you have the policy "leftsubnet=your-lan" and "rightsubnet=0.0.0.0/0"
>>> 
>>> But then again, iam no expert in strongswan...so you would please ask for advice and correct solution from the strongswan team itself
>>> 
>>> thanks
>>> rajiv
>>>  
>>> 
>>> 
>>>> On Sun, Sep 20, 2015 at 8:08 PM, Rayson Zhu <vfreex at gmail.com> wrote:
>>>> Hello all,
>>>> The gateway of my local site has a site-to-site VPN to my remote site.  I want to forward all traffic (including internet traffic) from my local site to  remote site.
>>>> 
>>>> The ipsec.conf in local gateway:
>>>> 
>>>> conn %default
>>>> 
>>>>         left=%any
>>>> 
>>>>         leftcert=<>
>>>> 
>>>>         leftid=<>
>>>> 
>>>>         leftauth=pubkey
>>>> 
>>>>         keyexchange=ikev2
>>>> 
>>>> conn site-to-site
>>>> 
>>>>         right=<remote_ip>
>>>> 
>>>>         rightid=<>
>>>> 
>>>>         rightauth=pubkey
>>>> 
>>>>         leftsubnet=10.10.0.0/23
>>>> 
>>>>         rightsubnet=0.0.0.0/0
>>>> 
>>>>         auto=add
>>>> 
>>>> 
>>>> 
>>>> After establishing the IPSec connection, the gateway can access to the internet through the tunnel, but at the same time the all hosts behind the gateway will lose connectivity to the gateway. 
>>>> 
>>>> That makes sense, because the config rule 'rightsubnet=0.0.0.0/0' tells IPSec to forward all traffic into tunnel, including the traffic to LAN. I added a passthrough policy like this:
>>>> 
>>>> conn bypasslan
>>>> 
>>>> 	leftsubnet=10.10.0.0/23
>>>> 
>>>>         rightsubnet=10.10.0.0/23
>>>> 
>>>>         type=passthrough
>>>> 
>>>> 	auto=route
>>>> 
>>>> But this policy does not work. Hosts in lan still cannot ping gateway.
>>>> 
>>>> I decided to use traceroute to see what is going on. The result shows that the traffic to LAN goes to the WAN interface without IPSec protection. I checked the route table and every thing looks normal. I tried adding a route rule 'ip route add 10.10.0.0/16 dev lan' but this didn't work.
>>>> 
>>>> I stop the IPSec tunnel, the connection between LAN hosts with the gateway comes back.
>>>> 
>>>> I will be very appreciate it if you can help me solve this problem.
>>>> 
>>>> 
>>>> 
>>>> Thanks & Regards,
>>>> 
>>>> Rayson
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.strongswan.org
>>>> https://lists.strongswan.org/mailman/listinfo/users
> 
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150921/d7992488/attachment.html>