Hello, as reported here if you try to configure a site to site vpn with ipsec, and your red interface is configured as PPPoE, the cockpit gui let you complete the process but the tunnel won’t start at all.
Just tested this on a fresh new installation on a APU2 pcengine updated with the latest update avaible, with subscription active.
Feb 7 08:30:44 rt01 pluto[5636]: loading secrets from "/etc/ipsec.secrets"
Feb 7 08:30:44 rt01 pluto[5636]: loading secrets from "/etc/ipsec.d/tunnels.secrets"
Feb 7 08:30:44 rt01 pluto[5636]: ERROR "/etc/ipsec.d/tunnels.secrets" line 12: index "%ppp0" illegal (non-DNS-name) character in name
Feb 7 08:30:44 rt01 pluto[5636]: initiating all conns with alias='s2stest_ipsec-tunnel'
[root@rt01 ~]# cat /etc/ipsec.d/tunnels.secrets
# ================= DO NOT MODIFY THIS FILE =================
#
# Manual changes will be lost when this file is regenerated.
#
# Please read the developer's guide, which is available
# at NethServer official site: https://www.nethserver.org
#
#
#
# 40clients
#
%ppp0 84.xx.xx.xx : PSK "randompassword1234!!"
Hi @francio87 , in your ipsec configuration there is the left side ID missing (identificatore locale), can you try to fill it with the IP of your ppp0 interface?
Ok, i’ve done some test, so if i set my public ip on the local identifier, the tunnel come up, and the error disappear.
But, if the pppoe connection drop and you don’t have a public static ip, when the pppoe come back the ip is different, and the tunnel won’t work ( but this time without secret error, just the standard auth mismatch)
So to work around this problem i’ve set on local identifier a ddns that point back to my public ip recived on ppp0 and the tunnel came back as soon the dns get auto updated // I know it’s not directly related to secret issue report above but maybe knowing that you can use a ddns (like an informational tooltip) can help some users or maybe auto-fill since we already know the public ip address of the ppp0 interface?.
Feb 7 13:29:37 demo pluto[25479]: "tests2sipsec_ipsec-tunnel/1x1" #3: negotiated connection [192.168.55.0-192.168.55.255:0-65535 0] -> [192.168.2.0-192.168.2.255:0-65535 0]
Feb 7 13:29:37 demo pluto[25479]: "tests2sipsec_ipsec-tunnel/1x1" #3: STATE_V2_IPSEC_I: IPsec SA established tunnel mode {ESP=>0xc849afe1 <0x812070c7 xfrm=AES_CBC_256-HMAC_SHA1_96 NATOA=none NATD=none DPD=active}
All in all,i guess to fix the secret issue reported, should be enough force the user to fill in the box with the external ip.
As a side note, if i use eth0 ( so no pppoe red interface ) the issue related to ERROR "/etc/ipsec.d/tunnels.secrets" line 12: index "%ppp0" illegal (non-DNS-name) character in name
won’t appear, i can leave it blank, it won’t connect but no errors pop up on the logs.
cheers
Good to know that is getting better!
About the dynamic ip my advice is to use a different syntax for local and remote identifier.
Usually when I have a natted red ip (so my red has a private ip) or a dynamic ip I suggest to use email like syntax in your NethServer and in the remote device.
This can be done always, even if you have both static public IPs.
You can put everything you want, the important thing is to have same things (inverted)in both devices.
E.g.:
Nethserver Side
local site1@nsec
remote site2@otherdevice
Other device
local site2@otherdevice
remote site1@nsec
You are right, but when i’ve found the secret issue, i was fighting with a Ubiquiti USG
As you can see here by default they seems to accept only the IP address and you can’t “easily” change, from the UI, the behaviour without messing with json and custom gateway (docs here) actually you can’t even use a ddns as remote peer on the UI.
I’ve mess also with ZyWall and other brands, and those parameters can be easily changed even from ui.
Can you feed USG with 0.0.0.0 as endpoint?
And something else than a IP Address as local/remote ID?
Zyxel allow “dynamic IP endpoint” as scenario, Ubiquiti Don’t?
