[strongSwan] IKE2 4500 Reply Not Making it Out

[Info]

On 03/23/2018 11:48 AM, Noel Kuntze wrote:
>> Anyone know why CentOS 7.4 with kernel 4.13.0-1.el7.elrepo.x86_64 makes an:
>> ipsec0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1400
>>         inet6 fe80::8ad2:285b:b89d:44ea  prefixlen 64  scopeid 0x20<link>
>>         unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
>>         RX packets 0  bytes 0 (0.0 B)
>>         RX errors 0  dropped 0  overruns 0  frame 0
>>         TX packets 0  bytes 0 (0.0 B)
>>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>> ... interface, when ipsec tunnels were supposed to have gone out years ago?  Could some of my traffic be getting diverted here?  Should this be set up in the firewall?
> That's because you're loading kernel-libipsec, which you shouldn't. Disable loading it.
> No, nothing is getting diverted there. No, don't set it up, because you're getting rid of it right now.
Gotten rid of.
# yum remove strongswan-libipsec
# systemctl restart strongswan-swanctl
No more ipsec0, thankfully.

> Anyone know why Strongswan seems to consider this the correct location
> for CA certs:
>> Mar 23 10:40:35 cygnus.darkmatter.org charon-systemd[41093]: loading ca certificates from '/etc/strongswan/ipsec.d/cacerts'
>> ... rather than:
>> Mar 23 10:40:35 cygnus.darkmatter.org charon-systemd[41093]: loaded certificate 'C=US, O=Quantum, CN=quantum-equities.com CA'
>> Mar 23 10:40:35 cygnus.darkmatter.org charon-systemd[41093]: 11[CFG] loaded certificate 'C=US, O=Quantum, CN=quantum-equities.com CA'
>> Mar 23 10:40:36 cygnus.darkmatter.org swanctl[41112]: loaded certificate from '/etc/strongswan/swanctl/x509ca/aries-CAcert.pem'
> It's because you're loading the stroke plugin, which you don't need.

Inferentially then it's considering
/etc/strongswan/swanctl/x509ca/aries-Cert.pem, trusted.

I'd specify plugins but it warns me to be an expert.  :j


>
>> Attached hereto:  charon.log and iptables-save.  SELinux is Permissive, and no firewall on the IPSec gateway.  No change.
> Those logs are too verbose, again. Please really use the logger configuration from the HelpRequests page.
I've always used the loglevels on the HelpRequests page except long
ago.  It's in charon.conf as per my pro forma email of today at US PDT
11:24.  Maybe this isn't the right way to set it?

> Is there anything logged by the kernel in its ring buffer?
> And please add the route I previously mentioned. And stop using ifconfig, or generally the net-tools.
>
> Kind regards
>
> Noel
The route you'd previously recommended was based on a mis-paste that I
had made.  The correct one is in my pro forma email.  Stopping using
net-tools, as evidenced by my pro forma email.

# dmesg
...
[929793.524099] device eth0 entered promiscuous mode
[929818.711290] device eth0 left promiscuous mode
[929841.911470] device eth0 entered promiscuous mode
[929873.259932] device eth0 left promiscuous mode
[929879.411366] device eth0 entered promiscuous mode
[929908.441305] device eth0 left promiscuous mode
[932883.537484] device eth0 entered promiscuous mode
[932918.924082] device eth0 left promiscuous mode
[935175.378065] device ipsec0 entered promiscuous mode
[935403.095266] device ipsec0 left promiscuous mode
[1002948.521841] device eth0 entered promiscuous mode
[1003442.985805] device eth0 left promiscuous mode
[1003452.933593] device eth0 entered promiscuous mode
[1003514.584868] device eth0 left promiscuous mode
[1018988.659360] device eth0 entered promiscuous mode
[1019027.076530] device eth0 left promiscuous mode
[1020862.863531] device eth0 entered promiscuous mode
[1020891.435220] device eth0 left promiscuous mode
[1090454.269266] device eth0 entered promiscuous mode
[1091211.518341] device eth0 left promiscuous mode





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180323/467be982/attachment.html>