Den lör 26 sep. 2026 kl 09:26 skrev Crystal Kolipe < [email protected]>:
> On Fri, Sep 25, 2026 at 01:36:36PM +0300, kasak wrote: > > When iked is off, lan network 192.168.0.0 can access 2.2.2.2 through wan. > > And 10.0.0.0 can access 1.1.1.1 through wan. > > But when iked is launched, only 1.1.1.1 and 2.2.2.2 can access > > one-to-another, and 192.168.0.0 can no longer access 2.2.2.2 and 10.0.0.0 > > cat no longer access 1.1.1.1 > > What exactly did you _expect_ to happen? > You've created a point to point link between the two hosts, using their > public > IPs. > I haven't done much with iked(8), but at least for isakmpd(8) ipsec setups, it could be a bit confusing when setting up a tunnel. I a "normal" tunnel scenario, like setting up gif(4) between two routers, you would expect routing tables to go "when talking to 2.2.2.2 use this interface", which would then be the gif(4) and all traffic to the remote side would get encapsulated regardless of if it was meant towards the endpoing router or any network behind it you knew of. With isakmpd(8) you would be able to set up a tunnel saying "from 1.1.1.1 to 2.2.2.2 use ipsec" and it would do the right thing when you test a ping from 1.1.1.1 towards 2.2.2.2, it gets encrypted and all that. Then if you have networks behind 1.1.1.1 and 2.2.2.2, the isakmpd policy would NOT affect traffic either from 192.168.x or to 10.x, because it would not match "from 1.1.1.1 to 2.2.2.2" exactly, like a simple layer-3 routing would (which only considers destinations) so you would have to add extra rules for "192.168.x to 10.x", "192.168.x to 2.2.2.2", "1.1.1.1 to 10.x" as well to get the "full" range of net to net, net to router, router to net and router to router. So the question on "what did you expect" may be that you were surprised either way if you expected normal routing rules when iked doesn't do normal, or expecting isakmpd behaviour if iked is different. -- May the most significant bit of your life be positive.
