[Openswan Users] Local router unable to send packets to remote LAN

lists lists at higgers.me.uk
Thu Dec 20 15:56:10 EST 2007


Ofcourse! It's so obvious when it's explained well! :-)

Many many thanks for telling me how to fix the problem Peter.

Steve.

Peter McGill wrote:
> Openswan only routes through the tunnel the traffic in specified subnets.
> So if you have leftsubnet=192.168.0.0/24 and rightsubnet=192.168.1.0/24,
> then traffic from your router will not use the tunnel, because it
> originates from 1.2.3.4 not 192.168.0.0/24. This is normal behaviour.
>
> However, if you add for example leftsourceip=192.168.0.1 to you conn.
> Assuming your using left for local, then that should use your LAN ip
> for communications from your router to your remote subnet. Thereby
> encrypting your router traffic to the subnet through your IPSec tunnel.
>
> Peter McGill
>  
>
>   
>> -----Original Message-----
>> From: users-bounces at openswan.org 
>> [mailto:users-bounces at openswan.org] On Behalf Of lists
>> Sent: December 20, 2007 8:27 AM
>> To: users at openswan.org
>> Subject: [Openswan Users] Local router unable to send packets 
>> to remote LAN
>>
>> Hi All,
>>
>> I've recently configured and IPsec VPN between my OpenSUSE 10.2 router
>> firewall running shorewall 3.4.4 and a friends Draytek Vigor 2930 ADSL
>> modem/router/firewall. All is good other than my router can't ping
>> anything on my friends (remote) LAN, however machines on my 
>> (local) LAN
>> behind the local firewall can ping machines on the remote LAN without
>> problem.
>>
>> The routing table on the route looks like this:
>>
>>
>>       1.2.3.0/24 dev eth2 proto kernel scope link src 1.2.3.4
>>       10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.1
>>       192.168.1.0/24 via 1.2.3.1 dev eth2
>>       192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.1
>>       169.254.0.0/16 dev eth0 scope link
>>       127.0.0.0/8 dev lo scope link
>>       default via 1.2.3.1 dev eth2
>>
>>
>>
>> Where:
>> 1.2.3.4 is my public IP
>> 1.2.3.1 is my ISP router at the other end of my ADSL line
>> 192.168.0.0/24 is the local LAN
>> 192.168.1.0/24 is the remote LAN
>> eth0 is the internal interface
>> eth2 is the external interface
>>
>> If I "ping 192.168.1.1 -I eth0" to force ping requests via the local
>> interface I get responses from the remote address. This also works for
>> any other live IP on the remote LAN. This proves that it's technically
>> possible to access the remote LAN from my router.
>>
>> If I delete the route to the remote LAN via eth2 (external 
>> NIC) and add
>> a new one via the internal NIC then no machines on my local LAN can
>> access the remote LAN. It basically screws the VPN.
>>
>> I use shorewall for firewall/routing duties and have tried 
>> disabling it
>> but it made no difference.
>>
>> I also added what I think are the correct entries to
>> /etc/racoon/setkey.conf but that didn't make any difference.
>>
>> It seems like I need to force all packets destined for the remote LAN
>> that originate on the local router to go via the internal NIC 
>> instead of
>> going via the external NIC. Is that possible? And if so, how?
>>
>> Also, would anyone happen to know if this is normal behaviour? I've
>> configured IPsec VPNs (using FreeS/WAN) under 2.4 in the past 
>> and never
>> had this problem. However, under 2.4 I'm sure the routing table was
>> different because there was a ipsec0 interface involved thus 
>> simplifying
>> the routing table. Well, it might not have simplified it per se but it
>> made would be a lot easier to direct packets for the remote LAN via an
>> interface designed specifically to pick up and push packets for the
>> remote LAN.
>>
>> What am I missing?
>>
>> Kind regards,
>>
>> Steve.
>>
>> _______________________________________________
>> Users at openswan.org
>> http://lists.openswan.org/mailman/listinfo/users
>> Building and Integrating Virtual Private Networks with Openswan: 
>> http://www.amazon.com/gp/product/1904811256/104-3099591-294632
>> 7?n=283155
>>     
>
>
>   



More information about the Users mailing list