Hello. I wonder how just correct couple of spdadd commands like spdadd 192.168.1.0/24 192.168.2.0/24 any -P out ipsec esp/tunnel/10.1.0.1-10.2.0.1/require; spdadd 192.168.2.0/24 192.168.1.0/24 any -P in ipsec esp/tunnel/10.2.0.1-10.1.0.1/require; makes _routing_ of packets from 192.168.1/24 into 192.168.2/24. If I understand correctly how it works on *BSD, these commands with make already tunneled traffic enrypted, routing is done before and besides ipsec SA and SP databases. On routing happens just like miracle. Ok, I would not ask all this if I have no problem with tunnelling. With configuration like described above, where multihomed maches have ip-addresses (192.168.1.1, 10.1.0.1) and (192.168.2.1, 10.2.0.1) tunneling works for all machines, but these two routers. This happenes becase if we send a packet from 10.1.0.1 into 192.168.2/24 this packet does not come to ipsec, but is pushed to default gateway, if it exists. In other words, local generated packets do not come through prerouting or something. -- Alexander Kotelnikov Saint-Petersburg, Russia
Alexander Kotelnikov schrieb:> Ok, I would not ask all this if I have no problem with > tunnelling. With configuration like described above, where multihomed > maches have ip-addresses (192.168.1.1, 10.1.0.1) and (192.168.2.1, > 10.2.0.1) tunneling works for all machines, but these two > routers. This happenes becase if we send a packet from 10.1.0.1 into > 192.168.2/24 this packet does not come to ipsec, but is pushed to > default gateway, if it exists. In other words, local generated packets > do not come through prerouting or something. >You have to add a route on 10.1.0.1 to make sure packets which belong to 192.168.2.0/24 have a src address of 192.168.1.1. Then the packet should go through the ipsec tunnel. Similar route in the other direction has to be used on 10.2.0.1. Cheers, Andreas
>>>>> On Mon, 05 Dec 2005 06:08:30 +0100 >>>>> "AU" == Andreas Unterkircher <unki@netshadow.at> wrote:AU> AU> Alexander Kotelnikov schrieb:>> Ok, I would not ask all this if I have no problem with >> tunnelling. With configuration like described above, where multihomed >> maches have ip-addresses (192.168.1.1, 10.1.0.1) and (192.168.2.1, >> 10.2.0.1) tunneling works for all machines, but these two >> routers. This happenes becase if we send a packet from 10.1.0.1 into >> 192.168.2/24 this packet does not come to ipsec, but is pushed to >> default gateway, if it exists. In other words, local generated packets >> do not come through prerouting or something. >>AU> You have to add a route on 10.1.0.1 to make sure packets which belong to AU> 192.168.2.0/24 have AU> a src address of 192.168.1.1. Very funny, how do you imagine this could be done? -- Alexander Kotelnikov Saint-Petersburg, Russia
ip ro add 192.168.2.0/24 via 10.2.0.1 dev ethx src 192.168.1.1 the spd policies will then match and encrypt the traffic. this is the same solution like you have to do for the freeswan ipsec stack. for me it works... Alexander Kotelnikov (sacha@myxomop.com) schrieb:> > >>>>> On Mon, 05 Dec 2005 06:08:30 +0100 > >>>>> "AU" == Andreas Unterkircher <unki@netshadow.at> wrote: > AU> > AU> Alexander Kotelnikov schrieb: > >> Ok, I would not ask all this if I have no problem with > >> tunnelling. With configuration like described above, where multihomed > >> maches have ip-addresses (192.168.1.1, 10.1.0.1) and (192.168.2.1, > >> 10.2.0.1) tunneling works for all machines, but these two > >> routers. This happenes becase if we send a packet from 10.1.0.1 into > >> 192.168.2/24 this packet does not come to ipsec, but is pushed to > >> default gateway, if it exists. In other words, local generated packets > >> do not come through prerouting or something. > >> > AU> You have to add a route on 10.1.0.1 to make sure packets which belong to > AU> 192.168.2.0/24 have > AU> a src address of 192.168.1.1. > > Very funny, how do you imagine this could be done? > > -- > Alexander Kotelnikov > Saint-Petersburg, Russia > > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >
>>>>> On Mon, 05 Dec 2005 10:42:23 +0100 >>>>> "AU" == Andreas Unterkircher <unki@netshadow.at> wrote:AU> AU> ip ro add 192.168.2.0/24 via 10.2.0.1 dev ethx src 192.168.1.1 AU> the spd policies will then match and encrypt the traffic. Uff... src in route... something really crazy, even thenks for the hint. Rather wild situation when one need to explicitly set up route for router own packets, while forwarded ones find their (same!) destination themself. -- Alexander Kotelnikov Saint-Petersburg, Russia