[strongSwan] Problem Routing Decrypted Packets
Sajal Malhotra
sajalmalhotra at gmail.com
Tue May 12 20:11:12 CEST 2015
Got some articles to help me with iptables update. I will try them once and
update.
Thanks and Regards
Sajal
On Tue, May 12, 2015 at 8:40 PM, Sajal Malhotra <sajalmalhotra at gmail.com>
wrote:
> Thanks a ton Noel for the clarification!!
> And I m Sorry that i missed your suggestion of using 0.0.0.0/0 in the
> first reply.
> In the mean time i tried testing with leftsubnet=10.3.4.22/32 and
> rightsubnet=172.18.21.232/32 and things worked perfectly fine.
>
> coming back to use of 0.0.0.0/0, can you provide some guideline, or any
> documentation that helps me with the use of iptables and mark_in, mark_out
> configuration?
>
> BR
> Sajal
>
> On Sun, May 10, 2015 at 9:44 PM, Noel Kuntze <noel at familie-kuntze.de>
> wrote:
>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Hello Sajal,
>>
>> With a TS of 0.0.0.0/32 == 0.0.0.0/32, no traffic will be tunneled,
>> because there is no traffic
>> ever that matches the policy set that is generated by that. An IP packet
>> with source 0.0.0.0
>> and destination 0.0.0.0 is invalid and will never be routed.
>> As I elaborated in the last email, you need to work with a TS of
>> 0.0.0.0/0 == 0.0.0.0/0
>> and then use marks in iptables and the mark_in and mark_out settings in
>> ipsec.conf
>> to define what traffic should be tunneled.
>> Alternatively, you can define several CHILD_SAs; one for each IP on the
>> remote (or local) side.
>>
>> Mit freundlichen Grüßen/Kind Regards,
>> Noel Kuntze
>>
>> GPG Key ID: 0x63EC6658
>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>>
>> Am 09.05.2015 um 15:01 schrieb Sajal Malhotra:
>> > Hi Noel,
>> >
>> > We actually want that all traffic from Host A shall be directed via
>> SeGW towards different Hosts behind Linux Box( which includes Host B as 1
>> one of the host ).
>> > There is only 1 tunnel and 1 child SA between SeGW and Linux Box.
>> > The Reason for keeping leftsubnet and rightsubnet as 0.0.0.0/32 <
>> http://0.0.0.0/32> is that there are multiple logical IPs (upto 3 IPs)
>> configured on Host A which send traffic towards different destinations
>> behind Linux Box (which also includes Host B)
>> > Is there any alternate want to configure the strongswan stack and linux
>> Box routing to handle this?
>> >
>> > BR
>> > Sajal
>> >
>> > On Sat, May 9, 2015 at 4:41 AM, Noel Kuntze <noel at familie-kuntze.de
>> <mailto:noel at familie-kuntze.de>> wrote:
>> >
>> >
>> > Hello Sajal,
>> >
>> > Tunneling 0.0.0.0/32 <http://0.0.0.0/32> == 0.0.0.0/32 <
>> http://0.0.0.0/32> does not work. What do you try to do?
>> > You need to decide on the subnets you want to tunnel or negotiate
>> 0.0.0.0/0 <http://0.0.0.0/0> == 0.0.0.0/0 <http://0.0.0.0/0>
>> > and then use mark(,_in,_out) to give the kernel information how to
>> handle the packets.
>> >
>> > Mit freundlichen Grüßen/Kind Regards,
>> > Noel Kuntze
>> >
>> > GPG Key ID: 0x63EC6658
>> > Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>> >
>> > Am 08.05.2015 um 12:53 schrieb Sajal Malhotra:
>> > > Hi,
>> >
>> > > I am using following Setup in my Lab:
>> >
>> > > Host A<---->SeGW<-----(ESP Tunnel)---->(eth1)Strongswan (Linux PC)
>> (eth0)<--->Host B
>> >
>> > > So there is one Tunnel Established between SeGW and Linux PC which is
>> running Strongswan Stack v5.2.2.
>> > > The Linux is connected to SeGW via its eth1 interface
>> > > and Host B is connected via eth0 Interface.
>> >
>> > > What we want is that:
>> > > 1. Any traffic that we want to send from Host A to Host B should go
>> via SeGW where it is sent encrypted towards Linux Box.
>> > > 2. The Linux Box running strongswan should then decrypt the traffic
>> and route it to Host B
>> > > 3. As expected, the reverse path to be followed for traffic from Host
>> B to Host A.
>> >
>> > > What we observe is that:
>> > > 1. SeGW is successfully able to encrypt the traffic and send ESP
>> frames to Linux PC
>> > > 2. the linux PC also decrypts it successfully
>> > > 3. However after decryption *it is not able to route *the traffic
>> towards interface connected to Host B. *On the contrary we see that
>> decrypted traffic is seen on the same interface from which it received the
>> ESP frames. i.e. the interface connected to SeGW. i.e. both Encrypted and
>> decrypted packet seen on same interface.*
>> >
>> > > The routing configured on Linux PC also looks to be correct as when I
>> send ping traffic from Host A to Host B (this traffic is not encrypted), i
>> see that Linux PC is correctly able to route this ICMP traffic towards Host
>> B without any Issue.
>> >
>> > > Can you let me know what could be the possible issue here. Or provide
>> some indication on how to debug it.
>> >
>> > > Below are the logs and configuration. Let me know if any additional
>> detail is needed that i missed--:
>> >
>> > > Here is the ipsec.conf connection setting:
>> >
>> >
>> >
>> > > conn saM
>> >
>> > > ikelifetime=24h
>> >
>> > > keyexchange=ikev2
>> >
>> > > keyingtries=%forever
>> >
>> > > keylife=5m
>> >
>> > > reauth=no
>> >
>> > > rekey=yes
>> >
>> > > mobike=no
>> >
>> > > dpdaction=clear
>> >
>> > > dpddelay=10
>> >
>> > > rekeymargin=1m
>> >
>> > > ike=aes128-sha1-modp1024,3des-sha1-modp1024!
>> >
>> > > esp=aes128-sha1-modp1024,3des-sha1-modp1024!
>> >
>> > > authby=rsasig
>> >
>> > > left=31.31.31.22
>> >
>> > > leftsubnet=0.0.0.0/32 <http://0.0.0.0/32> <http://0.0.0.0/32>
>> >
>> > > right=31.31.31.31
>> >
>> > > rightsubnet=0.0.0.0/32 <http://0.0.0.0/32> <http://0.0.0.0/32
>> >
>> >
>> > > leftprotoport=%any/%any
>> >
>> > > rightprotoport=%any/%any
>> >
>> > > leftcert=/usr/local/etc/ipsec.d/certs/linux.pem
>> >
>> > > rightid=%any
>> >
>> > > auto=add
>> >
>> >
>> > > Host A IP: 172.18.21.232
>> >
>> > > Host B IP: 10.3.4.22
>> >
>> >
>> > > *Routing Table on Linux PC:*
>> >
>> >
>> > > Kernel IP routing table
>> >
>> > > Destination Gateway Genmask Flags Metric Ref
>> Use Iface
>> >
>> > > 172.18.21.0 * 255.255.255.0 U 0 0
>> 0 eth1
>> >
>> > > *10.3.4.0 * 255.255.255.0 U 1 0
>> 0 eth0 <<<this route should have worked*
>> >
>> > > 192.168.122.0 * 255.255.255.0 U 0 0
>> 0 virbr0
>> >
>> > > 31.31.31.0 * 255.255.255.0 U 0 0
>> 0 eth1
>> >
>> > > 172.18.0.0 * 255.255.0.0 U 0 0
>> 0 eth1
>> >
>> > > default 10.3.4.1 0.0.0.0 UG 0 0
>> 0 eth0
>> >
>> > > default 10.3.4.1 0.0.0.0 UG 0 0
>> 0 eth0
>> >
>> >
>> > > *ifconfig output:*
>> > > [root at root ~]# ifconfig
>> > > eth0 Link encap:Ethernet HWaddr A4:1F:72:8E:66:F5
>> > > inet addr:10.3.4.139 Bcast:10.3.4.255 Mask:255.255.255.0
>> > > inet6 addr: fe80::a61f:72ff:fe8e:66f5/64 Scope:Link
>> > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> > > RX packets:33355 errors:0 dropped:0 overruns:0 frame:0
>> > > TX packets:32425 errors:0 dropped:0 overruns:0 carrier:0
>> > > collisions:0 txqueuelen:1000
>> > > RX bytes:18132226 (17.2 MiB) TX bytes:28624412 (27.2 MiB)
>> > > Interrupt:46 Base address:0x2000
>> >
>> > > eth1 Link encap:Ethernet HWaddr 00:0A:F7:16:7E:5D
>> > > inet addr:31.31.31.22 Bcast:31.31.31.255
>> Mask:255.255.255.0
>> > > inet6 addr: fe80::20a:f7ff:fe16:7e5d/64 Scope:Link
>> > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> > > RX packets:2807 errors:0 dropped:0 overruns:0 frame:0
>> > > TX packets:265 errors:0 dropped:0 overruns:0 carrier:0
>> > > collisions:0 txqueuelen:1000
>> > > RX bytes:395217 (385.9 KiB) TX bytes:35486 (34.6 KiB)
>> > > Interrupt:17
>> >
>> > > eth1:1 Link encap:Ethernet HWaddr 00:0A:F7:16:7E:5D
>> > > inet addr:172.18.21.1 Bcast:172.18.255.255
>> Mask:255.255.0.0
>> > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> > > Interrupt:17
>> >
>> > > Wireshark logs captured on eth1 interface are attached, which show
>> both encrypted and decrypted packets on same interface.
>> > > *
>> > > *
>> > > Thanks and Regards
>> > > Sajal
>> >
>> >
>> >
>> > > _______________________________________________
>> > > Users mailing list
>> > > Users at lists.strongswan.org <mailto:Users at lists.strongswan.org>
>> > > https://lists.strongswan.org/mailman/listinfo/users
>> >
>> >
>> >
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2
>>
>> iQIcBAEBCAAGBQJVT4PYAAoJEDg5KY9j7GZYj9YP/RHZhOsH7wrVGzDSJw7h5zVS
>> hkprCh9RZNKRHJAZB4uy+7wVOvRdOcp5VcziK0BndAYJVmYgzw/sP1ps6sK2HtFH
>> LgothvrMYU/k6sVUjBrVHxXT3EtIYaSpok+aalbkvtNyhPORaTXRlV355G8C7//Z
>> NH7jlCahCDm4Uis8GCz8FW6rzMzfnGP2ajec2xT4aEOtRGaBXpHgEYmZF9OsJit/
>> L1j/vBJ5OeNdmHSGduPN8WSvHpcEb/WNqjI8RhbXE0JlARnrN/D2rztVRKNjrCGz
>> L2xsjYq//DO+RODT5Tl37UkaTTOGaly8YszDZDHEuPT5t/widD+f3dge7UbJkc8M
>> prwIla6ZU29x3khIV7IbWV1zzHhjspY7Xx0NmN6dWVeLtPvm4ayZp+r+GRWsFxeC
>> KAoVuMhpQL0uqE0crqX4ggcMHoO4W4K+M6Ed3r4xhs5fgSZ2bVtZeglsXmt7VS/9
>> /QDapSCxvY5756e/KMnd3Jej2lChes1IEJmxamARd9sUVuh51T9QAEiT2tfOqIXs
>> marrqc3k0NRjif+7AU2pqRpKIUe+gnkFx97b6pCG6ZyAtBb4IcP9xazrMWrcIfvY
>> DoK9vgivxmulCVSiBoTeYq8RuYfbQAPk9q+GFk1nyHD9FVIJMwxZvJKPVHS9ssJR
>> G0TZKqFj6s7e6leOFpA0
>> =AmUW
>> -----END PGP SIGNATURE-----
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150512/474eeba2/attachment.html>
More information about the Users
mailing list