Re: [strongSwan] Restricting access to list of subnets
Hi Graham, > [ Strongswan is also using the list of allowed subnets to set up ip xfrm > policies. I'm not sure if I want these or understand them, but I'll leave > them be until I learn more about xfrm. ] Based on the older IPsec standards (RFC2401), the Linux kernel does not support (multiple) address ranges, but accepts a single subnet for a XFRM policy only. As per RFC4301, a leftsubnet=10.0.1.0/24,10.0.1.1/24 rightsubnet=10.0.2.0/24,10.0.2.1/24 configuration results in a single tunnel, allowing communication between any left to any right subnet. For Linux, this actually results in 4 policy groups, in/out/forward for 10.0.1.0/24 <-> 10.0.2.0/24 10.0.1.0/24 <-> 10.0.2.1/24 10.0.1.1/24 <-> 10.0.2.0/24 10.0.1.1/24 <-> 10.0.2.1/24 Hence the large number of installed policies. > Why would the remote end of the tunnel be interested in how I want to direct > traffic on- or off-tunnel ? Surely routing policy is a local decision ? With IKE, tunnels are completely negotiated. This also allows a receiving end to enforce tunnel usage, e.g. traffic to destination D must origin from source S and come through the AES encrypted tunnel T, while another destination B is required to use the NULL-encrypted tunnel R... This is the power of IPsec ;-). > Are responder traffic-selectors meant to tell the remote end what > traffic to send us down the tunnel and I should add explicit routes > (and not use "rightsubnets") to direct which locally-generated traffic > goes on- or off-traffic ? Usually you define what to tunnel by XFRM policies using left/rightsubnet definitions. Routes are primarily used to select the correct source address, i.e. use your received virtual IP to communicate within the tunnel. But as that source route decides what actually will match your tunnel definition, these must be set up carefully, too. Charon should do most of the work for you, installing a correct source route for all your remote subnets, but you might need to tweak some exceptions, such as access to a local subnet... Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Does strongswan always delete routes ?
Martin, Andreas, We're in the process of opting out of strongSwan managing routes when setting up and tearing down tunnels (by setting strongswan.conf's charon.install_routes option to 'no'). However, although strongswan is no longer installing the routes, whenever the tunnel goes down it looks like strongswan is still deleting the routes. Is this correct ? Desired ? If so, you may want to (ahem) amend the documentation warning developers of this :-) Regards, Graham. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Some possible strongSwan bugs
Hello all, I have been running strongSwan for a while on some of my networks and have been having a few stability issues. I am working on getting to root cause on a few of them and was wondering if other people are having these issues: 1.) DPD'd connections with dpaction=restart sometimes stop and never come back. The most common form of this is the CHILD_SA going away and never being re-established. I am working on getting better debug messages from charon and figuring out if charon is missing kernel notifications or if it just isn't establishing CHILD_SA's correctly. This problem seems to be worse over lower bandwidth connections. Most of the time this bug takes a while to hit. The first time I saw this bug was after ~ 57 hours of a tunnel working. The fastest I have hit this bug yet is ~ 19 hours. Some of my connections haven't hit this problem in the weeks they have been up. Some of these problems may be documented in: https://lists.strongswan.org/pipermail/users/2009-June/003516.html 2.) Sometimes connections will get into rekeying wars where both ends start displaying: deleting duplicate IKE_SA for peer 'w.x.y.z' due to uniqueness policy which causes a rekey, which causes a duplicate, which causes a rekey,... Note that only one end is configured to initiate the connection (auto=start, dpdaction=restart. The other end is (auto=add, dpdaction=clear)). This bug can also take hours/days to hit. This bug is pretty rare as I have only hit it twice in all my testing. 3.) Sometimes charon locks up. I have seen this happen in many different forms. I hit this style of bug maybe once a week. Unfortunately this bug family is really nasty as I have to kill process, restart processes, etc. Here is one such trace: gdb) thread apply all bt 15 Thread 6 (Thread 0x488304d0 (LWP 15785)): #0 0x0ff8df60 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x0ffd7360 in ?? () from /usr/lib/libstrongswan.so.0 #2 0x10023884 in schedule (this=0x10067f28) at processing/scheduler.c:223 #3 0x100219d8 in execute (this=0x100680e0) at processing/jobs/callback_job.c:145 #4 0x100242e4 in process_jobs (this=0x1006a0b8) at processing/processor.c:123 #5 0x0ff87b34 in start_thread () from /lib/libpthread.so.0 #6 0x0fdf8b94 in clone () from /lib/libc.so.6 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 5 (Thread 0x490304d0 (LWP 15786)): #0 0x0ff92594 in recvfrom () from /lib/libpthread.so.0 #1 0x0f811720 in receive_events (this=) at kernel_netlink_ipsec.c:748 #2 0x100219d8 in execute (this=0x1006e550) at processing/jobs/callback_job.c:145 #3 0x100242e4 in process_jobs (this=0x1006a0b8) at processing/processor.c:123 #4 0x0ff87b34 in start_thread () from /lib/libpthread.so.0 #5 0x0fdf8b94 in clone () from /lib/libc.so.6 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 4 (Thread 0x498304d0 (LWP 15787)): #0 0x0ff92594 in recvfrom () from /lib/libpthread.so.0 #1 0x0f8175c0 in receive_events (this=0x1006e620) at kernel_netlink_net.c:498 #2 0x100219d8 in execute (this=0x1006e7a8) at processing/jobs/callback_job.c:145 #3 0x100242e4 in process_jobs (this=0x1006a0b8) at processing/processor.c:123 #4 0x0ff87b34 in start_thread () from /lib/libpthread.so.0 #5 0x0fdf8b94 in clone () from /lib/libc.so.6 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 3 (Thread 0x4a0304d0 (LWP 15788)): #0 0x0ff8d930 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x0ffd74ec in ?? () from /usr/lib/libstrongswan.so.0 #2 0x100213f4 in send_packets (this=0x10070888) at network/sender.c:97 #3 0x100219d8 in execute (this=0x100709d8) at processing/jobs/callback_job.c:145 #4 0x100242e4 in process_jobs (this=0x1006a0b8) at processing/processor.c:123 #5 0x0ff87b34 in start_thread () from /lib/libpthread.so.0 #6 0x0fdf8b94 in clone () from /lib/libc.so.6 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 2 (Thread 0x4a8304d0 (LWP 15791)): #0 0x0fdf0798 in select () from /lib/libc.so.6 #1 0x1004b5f8 in receiver (this=0x10069020, packet=0x4a82f93c) at network/socket-raw.c:148 #2 0x10020b7c in receive_packets (this=0x10070aa8) at network/receiver.c:266 #3 0x100219d8 in execute (this=0x10070b88) at processing/jobs/callback_job.c:145 #4 0x100242e4 in process_jobs (this=0x1006a0b8) at processing/processor.c:123 #5 0x0ff87b34 in start_thread () from /lib/libpthread.so.0 #6 0x0fdf8b94 in clone () from /lib/libc.so.6 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 1 (Thread 0x48022110 (LWP 15780)): #0 0x0ff8d930 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x0ffd74b8 in ?? () from /usr/lib/libstrongswan.so.0 #2 0x10030a5c in flush (this=0xfff701c) at sa/ike_sa_manager.c:1552 #
