Support with N2N and IP / ddns

Hello, I’m new here and am trying to get a network-to-network connection with Core 150. Just by the way, I’m not an IT technician … I do it privately, but I’m really excited about IPfire & Co.
First the costellation:
have two small computers, each with 3 ethernet etc … IpFire on it with a Core 150.
As an internet provider I have Kabel Deutschland or Vodafon with 1GB line.
The problem I now have is that I can only get the connection established if I use the IP address of the remote station in both IPfire servers. Since the IP address changes from time to time, I have to rely on no-ip.
And that’s where the problems begin. My “main office” updates the IP regularly at no-ip, unfortunately my “branch office” doesn’t … I also don’t get a log entry … It just means that an update has been made.
So far I have used myself to update the IP manually with no-ip …
But if I enter XXvpn.ddns.net in the respective “remote host”, no connection is established … it always remains on reconnecting.
Doesn’t that work with a no-op address? with no-ip I also “bought” an account as if there shouldn’t be any problems here.
Could you help me with this?
A Roadwarrion connection with xxx.ddns.net connection, however, works …

Would be really nice if someone could help me … Thank you in advance and best regards M.

Hi,

this sounds strange. Could you post those “success” log message(s) here anyway?

Referring to the documentation, the DDNS FQDNs change their colours from red to green in case they have been successfully updated. If they do, I would expect that FQDN to resolve to the correct IP address as well (unless there is some high TTL on it).

You do get a public IPv4 address each time you reconnect, don’t you?

Thanks, and best regards,
Peter Müller

Hello,
Thank you for the feedback.

I tried it several times instead of an IP to enter the dyndns … so in my case xxxxxx.ddns.net. The strange thing is that on the server side it is then red with the label “Reconnection” and on the field office the field is only red but there is nothing inside. so far i haven’t tested whether this will change after a while. I will catch up immediately tomorrow.

Of course I can also post log here, I have no problem with that.
Come tomorrow…

Yes, I also have Kabel Deutschland or Vodafon with 1GB and I also have an IPv4 address, correct.

Unfortunately, this only changes from time to time, is like telecommunications shows every 24 hours … uh :slight_smile: but a 1GB line from Vodafon with a fixed IP is only available in connection with a business customer contract and then it costs around € 50 and from umpteenth month even 79 what I’ve read … it’s a shame …

Best regards and have a nice evening!
M. S.

Hello Mr. Müller, unfortunately I haven’t had time to take care of it … but now I’m here! :slight_smile:
What exactly should I provide for a protocol? Feel free to write further information …

Your second “question” … TTL not that I know of …

regards
M.

Meanwhile, I found some spare time to reply on this, I hope the information provided is suitable for solving.

In the settings GUI, there is only a red box visible, but with no text in it.

global settings

N2N settings

related log messages:

[root@MSFW01 ~]# tail -f /var/log/messages | grep n2n
Nov  7 12:07:26 MSFW01 NetN2N[10747]: event_wait : Interrupted system call (code=4)
Nov  7 12:07:26 MSFW01 NetN2N[10747]: /sbin/ip route del 192.168.0.0/24
Nov  7 12:07:26 MSFW01 NetN2N[10747]: ERROR: Linux route delete command failed: external program exited with error status: 2
Nov  7 12:07:26 MSFW01 NetN2N[10747]: Closing TUN/TAP interface
Nov  7 12:07:26 MSFW01 NetN2N[10747]: /sbin/ip addr del dev tun1 local 10.10.1.1 peer 10.10.1.2
Nov  7 12:07:26 MSFW01 NetN2N[10747]: Linux ip addr del failed: external program exited with error status: 2
Nov  7 12:07:26 MSFW01 NetN2N[10747]: SIGTERM[hard,] received, process exiting
Nov  7 12:07:26 MSFW01 NetN2N[13401]: disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Nov  7 12:07:26 MSFW01 NetN2N[13401]: WARNING: Using --management on a TCP port WITHOUT passwords is STRONGLY discouraged and considered insecure
Nov  7 12:07:26 MSFW01 NetN2N[13401]: OpenVPN 2.4.9 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Oct  5 2020
Nov  7 12:07:26 MSFW01 NetN2N[13401]: library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.09
Nov  7 12:07:26 MSFW01 NetN2N[13402]: MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:2000
Nov  7 12:07:26 MSFW01 NetN2N[13402]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Nov  7 12:07:26 MSFW01 NetN2N[13402]: Diffie-Hellman initialized with 2048 bit key
Nov  7 12:07:36 MSFW01 NetN2N[13402]: RESOLVE: Cannot resolve host address: [DDNSNAME].ddns.net:2000 (Name or service not known)
Nov  7 12:07:36 MSFW01 NetN2N[13402]: ROUTE_GATEWAY 188.193.6.2/255.255.255.0 IFACE=red0 HWADDR=xxxxxxxxxxxx
Nov  7 12:07:36 MSFW01 NetN2N[13402]: TUN/TAP device tun1 opened
Nov  7 12:07:36 MSFW01 NetN2N[13402]: TUN/TAP TX queue length set to 100
Nov  7 12:07:36 MSFW01 NetN2N[13402]: /sbin/ip link set dev tun1 up mtu 1500
Nov  7 12:07:36 MSFW01 NetN2N[13402]: /sbin/ip addr add dev tun1 local 10.10.1.1 peer 10.10.1.2
Nov  7 12:07:36 MSFW01 NetN2N[13402]: /etc/init.d/static-routes start tun1 1500 1605 10.10.1.1 10.10.1.2 init
Nov  7 12:07:36 MSFW01 NetN2N[13402]: /sbin/ip route add 192.168.0.0/24 via 10.10.1.2
Nov  7 12:07:46 MSFW01 NetN2N[13402]: RESOLVE: Cannot resolve host address: [DDNSNAME].ddns.net:2000 (Name or service not known)
Nov  7 12:07:46 MSFW01 NetN2N[13402]: Could not determine IPv4/IPv6 protocol
Nov  7 12:07:46 MSFW01 NetN2N[13402]: GID set to nobody
Nov  7 12:07:46 MSFW01 NetN2N[13402]: UID set to nobody
Nov  7 12:07:46 MSFW01 NetN2N[13402]: SIGUSR1[soft,init_instance] received, process restarting
Nov  7 12:07:46 MSFW01 NetN2N[13402]: Restart pause, 5 second(s)
Nov  7 12:07:46 MSFW01 NetN2N[13402]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:2000
Nov  7 12:07:46 MSFW01 NetN2N[13402]: MANAGEMENT: CMD 'state'
Nov  7 12:07:46 MSFW01 NetN2N[13402]: MANAGEMENT: TCP send error: Broken pipe
Nov  7 12:07:46 MSFW01 NetN2N[13402]: MANAGEMENT: Client disconnected
Nov  7 12:07:51 MSFW01 NetN2N[13402]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Nov  7 12:08:01 MSFW01 NetN2N[13402]: RESOLVE: Cannot resolve host address: [DDNSNAME].ddns.net:2000 (Name or service not known)
Nov  7 12:08:01 MSFW01 NetN2N[13402]: Preserving previous TUN/TAP instance: tun1
Nov  7 12:08:11 MSFW01 NetN2N[13402]: RESOLVE: Cannot resolve host address: [DDNSNAME].ddns.net:2000 (Name or service not known)
Nov  7 12:08:11 MSFW01 NetN2N[13402]: Could not determine IPv4/IPv6 protocol
Nov  7 12:08:11 MSFW01 NetN2N[13402]: SIGUSR1[soft,init_instance] received, process restarting
Nov  7 12:08:11 MSFW01 NetN2N[13402]: Restart pause, 5 second(s)

As you can see, [DNSNAME].ddns.net won’t be resolved, which is why no connection can be established. If I put in the public IPv4 address directly, it works.
Unfortunately, I was unable to find an explanation for this issue.

I would be very grateful for any hints to this problem.

Best regards,
M.

Hi M.
what jumps into eye was

MANAGEMENT: TCP send error: Broken pipe

which causes no message in the WUIs flag. Did you restart OpenVPN-N2N or may the machine ?

Did you checked if the DDNS resolves indeed your IP e.g.

curl -s https://api.ipify.org

should deliver the same IP as

ping [DNSNAME].ddns.net

if not your DDNS is not updated or inactive.

Some ideas.

Best,

Erik

1 Like

Hello Erik,

Thank you for your reply.

I first had an IPv4 address inside, but then entered a ddns.address for the test and had the connection re-established myself.
I also tested it with a complete restart of the OVPN server, the log was identical.

The DDNS address is resolved correctly …

zz_03

If I interpret it like that, is this behavior not normal?

Best regards, M.

Maybe you have another idea?
Best regards, M

Hi,

first, sorry for being silent that long here. :expressionless:

Second, this is strange indeed. Usually, quirks at the DDNS FQDN cause such issues, but in this case, it seems to be something else.

I was tempted to blame a commercial router in the first place (the FritzBoxes cause some rather interesting problems on UDP DNS queries to the root nameservers), but since an OpenVPN connection can be established if the public IPv4 address of the peer is entered, this does not apply on @misi08’s issue.

@misi08: Do you experience any other DNS-related issues sometimes?

Apart from that, I am out of ideas for this. :frowning:

Thanks, and best regards,
Peter Müller