Can I disable the "ECHO" packet when using SecureNAT?

[zhoudu]

Hi,

I have used SoftEther VPN Server to set up a L2TP (over IPSec) VPN server. This server uses SecureNAT (both NAT and DHCP). Now this server works well. But there is a small problem: After using Wireshark to capture packets in the VPN layer (which is named ppp0, on a MacBook Pro), I find that there are some "ECHO" packets (Wireshark says that the protocol of these packets is "ECHO") sent to the virtual client IP address. The "ECHO" data is "SecureNAT Virtual TCP/IP Stack Beacon". Every such packet is sent around every 5 seconds. I also find that the virtual client IP address doesn't reply these "ECHO" packets.

Why are there such packets? And, can I disable sending such packets?

[moatazelmasry]

Most probably this is used to determine whether is the client is still alive.

From the Manual:
https://www.softether.org/index.php?tit ... CP_Servers
"
When virtual NAT is enabled, sending ICMP packets via IP addresses assigned by a virtual host network interface as routers, and further sending said packets to a separate host results in the virtual NAT returning dummy ICMP echo response packets to all ICMP echo request packets. This is a specification of the SoftEther VPN whereby this operation becomes inevitable because most operating systems do not allow the transmission of arbitrary ICMP packets in network APIs which can be called up with user authority. When using Virtual NAT it is therefore impossible to confirm the existence of a host on the other side of a Virtual NAT router using ICMP packets.
"

[zhoudu]

moatazelmasry wrote:
> Most probably this is used to determine whether is the client is still
> alive.
>
> From the Manual:
>
> https://www.softether.org/index.php?tit ... CP_Servers
> "
> When virtual NAT is enabled, sending ICMP packets via IP addresses assigned
> by a virtual host network interface as routers, and further sending said
> packets to a separate host results in the virtual NAT returning dummy ICMP
> echo response packets to all ICMP echo request packets. This is a
> specification of the SoftEther VPN whereby this operation becomes
> inevitable because most operating systems do not allow the transmission of
> arbitrary ICMP packets in network APIs which can be called up with user
> authority. When using Virtual NAT it is therefore impossible to confirm the
> existence of a host on the other side of a Virtual NAT router using ICMP
> packets.
> "

It seems that the "ECHO" packets are not ICMP packets. I tried performing ping inside the VPN and captured the traffic inside the VPN, and found that the ping packets were directly packed in IPv4 packets. However, after capturing the "ECHO" packets, I found that the "ECHO" packets were packed in UDP packets, not directly packed in IPv4 packets. So, it seems that they are different.

Probably the "ECHO" packets are used by the VPN server to determine whether the client is still alive. But, I don't want to have them. Also, the client is not responding to those packets, so they don't make sense. Anyway, is there a way to let the VPN server not send them?

Thanks.

[moatazelmasry]

I assume these packets are there because they are part of an RFC (probably ppp) and must be implemented for the protocol to function correctly.

What do you mean packet in IPv4 packets? Do you mean in TCP packets??
Whether they are packed as TCP or UDP makes no difference, I think the client makes a protocol suggestion and the server can fulfill both, so it just accepts the client's suggestion.

As far as I see in the code, the ECHO definition is an ICMP (src/Mayaqua/TcpIp.h)

I'm not aware of any confiugration in the UI that lets you change/disable the echo period.

If you really want to change the value, or turn it off completely, here are 2 places in the source code that might help:

src/Cedar/IPsec_PPP.h:140:#define PPP_ECHO_SEND_INTERVAL 4792 // Transmission interval of PPP Echo Request
#This value is in milliseconds. Increase it to your need

src/Cedar/IPsec_PPP.c:492: p->NextEchoSendTime = now + (UINT64)PPP_ECHO_SEND_INTERVAL;
#I think you can disable this line

Disclaimer, I didn't try any of this. But it is worth a try

Cheers

[zhoudu]

moatazelmasry wrote:
> I assume these packets are there because they are part of an RFC (probably ppp) and
> must be implemented for the protocol to function correctly.
>
> What do you mean packet in IPv4 packets? Do you mean in TCP packets??
> Whether they are packed as TCP or UDP makes no difference, I think the client makes a
> protocol suggestion and the server can fulfill both, so it just accepts the client's
> suggestion.
>
> As far as I see in the code, the ECHO definition is an ICMP (src/Mayaqua/TcpIp.h)
>
> I'm not aware of any confiugration in the UI that lets you change/disable the echo
> period.
>
> If you really want to change the value, or turn it off completely, here are 2 places
> in the source code that might help:
>
> src/Cedar/IPsec_PPP.h:140:#define PPP_ECHO_SEND_INTERVAL 4792 // Transmission
> interval of PPP Echo Request
> #This value is in milliseconds. Increase it to your need
>
> src/Cedar/IPsec_PPP.c:492: p->NextEchoSendTime = now +
> (UINT64)PPP_ECHO_SEND_INTERVAL;
> #I think you can disable this line
>
> Disclaimer, I didn't try any of this. But it is worth a try
>
> Cheers

It seems that the "ECHO" packets are not necessary, because I have used other VPNs and have captured packets inside them, and found no such packets. In fact, I only find such "ECHO" packets in VPNs established by SoftEther VPN.

And, by referring to packets packed in IP, I mean, they are neither packed in TCP or UDP, but directly in IP. This is the case for ping packets, which you can capture and see. But, this is not the case for those "ECHO" packets, which are packed in UDP. By saying this, I want to express that it seems that those "ECHO" packets are not ping packets. But, well, they may also be ICMP packets. I don't know much about network protocols.

Anyway, it seems that those "ECHO" packets are not necessary. I hope that you provide an official way (probably in a new version of SoftEther VPN) to allow the VPN server administrator to disable the "ECHO" packets.

Thanks!

[moatazelmasry]

Hi,

I'm not a project maintainer, but only interested in the project.
Anyway I think this is only a minor issue, since it is not causing much trouble. But you should open an issue on github if you think it is important

Another idea for now to block those icmp's is to do it on the OS level using iptables:
iptables -A OUTPUT -p icmp --icmp-type echo-request -j DROP

If this doesn't work, you can try the same on the NAT POSTROUTING chain:
iptables -t nat -A POSTROUTING -p icmp --icmp-type echo-request -j DROP

[zhoudu]

moatazelmasry wrote:
> Hi,
>
> I'm not a project maintainer, but only interested in the project.
> Anyway I think this is only a minor issue, since it is not causing much
> trouble. But you should open an issue on github if you think it is
> important
>
> Another idea for now to block those icmp's is to do it on the OS level
> using iptables:
> iptables -A OUTPUT -p icmp --icmp-type echo-request -j DROP
>
> If this doesn't work, you can try the same on the NAT POSTROUTING chain:
> iptables -t nat -A POSTROUTING -p icmp --icmp-type echo-request -j DROP

Thank you!

[moatazelmasry]

Hi,

I just stumbled upon a couple of commands regarding keep-alive in the "vpncmd" tool. Maybe this is what you are looking for:

KeepDisable - Disable the Keep Alive Internet Connection Function
KeepEnable - Enable the Keep Alive Internet Connection Function
KeepGet - Get the Keep Alive Internet Connection Function
KeepSet - Set the Keep Alive Internet Connection Function

[thisjun]

Please try to drop the ECHO packet by accesslist function.
http://www.softether.org/4-docs/1-manua ... ccess_List

[pwhooftman]

I'm using my Softether VPN server in conjunction wit a Teltonika RUT240 4G router. Minimal data usage is important because of the prepaid plan active on the 4G routers sim card, so i disabled IP4polling and ARPpolling.

At first, these securenat polls remained despite disabling IPv4 & ARP polling , with the RUT240 router ('CAMPER') responding every 5 seconds:

Code: Select all

2023-10-18,13:50:21.212,SID-SECURENAT-1,-,5E9E64846062,FFFFFFFFFFFF,0x0800,80,UDPv4,-,192.168.30.1,echo(7),192.168.30.255,echo(7),-,-,-,-,-,-
2023-10-18,13:50:21.212,SID-SECURENAT-1,-,5E9E64846062,FFFFFFFFFFFF,0x0806,42,ARPv4,Response,-,-,-,-,-,-,5E9E64846062 has 192.168.30.1,-,-,-
2023-10-18,13:50:21.283,SID-CAMPER-[OPENVPN_L3]-99,SID-SECURENAT-1,CA81CDAA8ADC,5E9E64846062,0x0800,108,ICMPv4,-,192.168.30.17,-,192.168.30.1,-,-,-,-,-,172.17.0.1(port=33153),-

Thanks to this thread i was able to reduce this by filtering packets with destination 192.168.30.255, but i can't get rid of the last SecureNat poll requests every 5 seconds:

Code: Select all

2023-10-18,18:05:20.532,SID-SECURENAT-1,-,5E9E64846062,FFFFFFFFFFFF,0x0806,42,ARPv4,Response,-,-,-,-,-,-,5E9E64846062 has 192.168.30.1,-,-,-
2023-10-18,18:05:25.557,SID-SECURENAT-1,-,5E9E64846062,FFFFFFFFFFFF,0x0806,42,ARPv4,Response,-,-,-,-,-,-,5E9E64846062 has 192.168.30.1,-,-,-
2023-10-18,18:05:30.560,SID-SECURENAT-1,-,5E9E64846062,FFFFFFFFFFFF,0x0806,42,ARPv4,Response,-,-,-,-,-,-,5E9E64846062 has 192.168.30.1,-,-,-

Someone know a way to eliminate these ARPv4 responses? I tried blocking packets originated from and to the mac address, but somehow these packets remain. I'm not sure these are transmitted on the connection to the 4G router, but i do see the 'transferred bytes' in the session keeps rising,at about a third of the rate before filtering 192.168.30.255. The only way to reduce idle traffic on the 4G router altogether seems to disconnect it from the vpn server.

[solo]

Someone know a way to eliminate these ARPv4 responses?
...
The only way to reduce idle traffic on the 4G router altogether seems to disconnect it from the vpn server.

These internal ARPs do not register on Wireshark and can not possibly have any impact on your data costs. The 4G idle traffic you observe is related to DDNS, NAT-T and VPN Azure. You could disable them on ISPs which allow incoming connections, but it is usually not an option on 4G.