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