Open lars18th opened 5 years ago
First of all we have to add a proto handler not netifd. After that is done we could add this to the LuCI.
First of all we have to add a proto handler not netifd.
Then we need developers to implement this. It's hard to do it?
Hi @feckert ,
First of all we have to add a proto handler not netifd.
Any guide to read in order to implement it?
@lars18th Can you show how you use FOU on Openwrt ? Maybe small how-to example ? ip fou add port 5555 ipproto 4 doesn't work for me (kmod-fou is installed)
Hi @Lankaster ,
I put here an example with GUE inside OpenWRT (remember: FOU is IP-over-IP, GUE is Ethernet-over-IP):
ip fou add port 9991 gue
ip link add dev gretap1 type gretap remote $IP_REMOTE local $IP_LOCAL encap gue encap-sport auto encap-dport 9991
ip link set gretap1 up
And that's all! I'm using it in several OpenWRT routers with success for several months.
You can change the gue
with fou
if you want a L3 tunnel instead of a L2. And remember that GUE/FOU encapsulates all inside a simple UDP datagrams. So, you need only to set-up the IP:PORT pairs of both: local and remote hosts. The port 5555
is only the default udp port for FOU encapsulation, but this is not relevant as you can use any free port.
I hope this helps to develop the proto handler scripts for these must-have protocols. Regards.
Hi,
Nearly a year after the last post, I want to reask about the support for GUE/FOU protocols in OpenWRT. Please, take note that the implementation of the protocols are already included in the kernel years ago. So the next step is to create the "proto handler" for these tunneling protocols. And as I don't have any experience with this, I ask to someone to try to implement it. Examples of the commands are in my previous message. They are only 3 commands to execute to start the tunnel (with the exception of the firewall rules).
In any case, please, note that such family of protocols FOU & GUE are be far more simple-robust-efficient-etc than any other tunneling protocols. Please, forget the GRE encapsulation, the complexity of VXLAN, the non-standard protocols like Mikrotik EoIP, and all VPN based connections. For tunneling nothing than encapsulating over UDP datagrams is more simple, flexible and efficient.
Please, consider it. Regards.
@lars18th It seams GUE Protocol are really simple to implement. First question: Which parameters we need for GUE protocol ?
Can we use different portnumber for source and destination or it should be same ?
---------------FOU Example----------------
$ ip fou add port 42424 ipproto 4
$ ip link add name fou0 type ipip \
remote <VM-IP> local <OPENWRT-IP> \
encap fou encap-sport 42424 encap-dport 42424
$ ip link set fou0 up mtu 1472
$ ip addr add 10.7.7.1/24 dev fou0
Hi @Lankaster ,
I can try to add this protocols as additional package (vpnc and wireguard are good examples) .... but because of lack free time it can take several month.
Great! I'm not in a hurry, because I can work with command line (the kernel support is included). :wink:
@lars18th It seams GUE Protocol are really simple to implement.
Yes, FOU/GUE are very simple to manage and not difficult to configure. They're simple L2/L3-over-UDP tunnels. Very fast and robust. Therefore, a perfect replacement for all other tunnelling protocols. However, I don't know anything about how to implement support in OpenWRT (for CLI first, and for LUCI after).
First question: Which parameters we need for GUE protocol ?
One starting point to understand these protocols is this small guide: https://developers.redhat.com/blog/2019/05/17/an-introduction-to-linux-virtual-interfaces-tunnels#fou Please, read it.
- Source address
- Destination address
- Port number
Regarding the ip
command parameters, I recommend to read the official man page:
https://man7.org/linux/man-pages/man8/ip-gue.8.html
Can we use different portnumber for source and destination or it should be same ?
Please, take note that you can define all four parameters:
port AAA
is the listening UDP port.local BBB.BBB.BBB.BBB
is the listening address.peer CCC.CCC.CCC.CCC
is the remote address of the tunnel.peer_port DDD
is the remote UDP port.So, yes, you can listen in 192.168.1.50:9999 and the remote can use 192.168.255.100:8888. Remember: are pure UDP packets so you manage the pair ADDR:PORT in both ends.
Other comment to note: if you want to use GUE then the command is ip fou add port AAA gue local BBB.BBB.BBB.BBB peer CCC.CCC.CCC.CCC peer_port DDD
. With the GUE encapsulation all IP packets sended to the tunnel will arrive to the other end. However, when using FOU only IP packets of the indicated protocol will arrive. That's the difference between FOU & GUE. And if you want to create a TUN or TAP device for the tunnel, then it's preferable to use FOU with the corresponding protocol (GRE or IPIP). But in case you want to directly route IP datagrams over the tunnel, then the GUE protocol is preferable (it pass all).
---------------FOU Example----------------
$ ip fou add port 42424 ipproto 4 $ ip link add name fou0 type ipip \ remote <VM-IP> local <OPENWRT-IP> \ encap fou encap-sport 42424 encap-dport 42424 $ ip link set fou0 up mtu 1472 $ ip addr add 10.7.7.1/24 dev fou0
This example is correct. You encapsulate IPIP packets over a FOU tunnel that uses UDP datagrams (using the port 42424 in both ends). This is the common way to create L3 tunnels (FOU+IPIP).
I hope you want to add the proto handler for FOU & GRE. Regards.
Hi,
Recent OpenWRT kernels have FOU and GUE support. However in the official documentation about tunnelling protocols they are missing: https://openwrt.org/docs/guide-user/network/tunneling_interface_protocols
This is because these protocols are recently added. So, it will be interesting to have support for them in the LUCI interface.
If you need more info about them read: http://man7.org/linux/man-pages/man8/ip-gue.8.html However, think you on these protocols as the best replacements for "gretap" and "eoip"/"ipip"/etc. The transport layer is pure UDP so it's easy to manage. And it can encapsulate anything; so L2 & L3 tunnels are possible using a simple UDP flow.
I'm using both manually, so I hope someone think on add support for them in LUCI. Regards.