[strongSwan] Problem Routing Decrypted Packets
Sajal Malhotra
sajalmalhotra at gmail.com
Tue May 12 17:10:39 CEST 2015
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/9ea4231c/attachment.html>
More information about the Users
mailing list