esp_wireguard
esp_wireguard copied to clipboard
Compatibility with esp_modem?
Sorry that i'm missusing an Issued to ask a question!
I've been trying to get wireguard running over via sim800/sim7000 GSM/LTE Modems and to run mqtt (not via http bit via native protocol) over the wireguard tunnel.
My old solution uses arduino-libs, e.g. tinygsm and pubsubclient which both do not work with wireguard. (Pubsubclient needs a client object in it's initializer which could be wifi client or gsmclient, but not (arduino-)wireguard, and the arduino-wireguard tunnel will not run over tinygsm links).
As this (and the Arduino "version" of wireguard) uses lwip, bit tinygsm client does not I guess the trick is to switch to espidf and libs that use lwip.
So I came to the idea that using esp_modem for the PPP link and this wireguard lib here I should have a basis to use an lwip aware mqtt client.
But I've no idea about lwip interfaces, routes,.... IMHO my guess would be that wireguard registers a lwip interface (https://github.com/trombik/esp_wireguard/blob/a441e52b5a117f3dc3caa01376726d9dc9331192/src/esp_wireguard.c#L185) and somehow the default-route is applied to it. But on the other hand the esp_modem would like to do the same, but there's no netif_add in it's code (https://github.com/espressif/esp-protocols/tree/master/components/esp_modem) and there's no hint about adding routes?
So both interfaces would need to be daisy-chained from a routing point - wireguard if should be default gateway, but it should have a route that forwards everything to the PPP interface.
But how could this be accomplished? I'm thankful for any hint as I'm stuck.
Thanks and Best Regards, Martin.
a very interesting configuration. i'm not an expert of lwip
, but my understanding is that lwip
does not support a routing table as you normally expect on U*nix machines. haven't looked at esp_modem
code yet, but i guess you would need some modifications in esp_modem
first?
esp-idf
version 5.x introduced more abstractions into esp-netif
. i'm thinking about porting esp_wireguard
to esp-netif
so that the library does not depend on the underling TCP/IP layer. however, that is a major change.
Hi,
i did some more reading on this issue in the context of lwip. there's 3 takeaways i'll investigate the next time (the esp32 is in a remote location, will be there in ~3 weeks again for some days).
- lwip allows to set a default interface - i think the wireguard-tunnel-if should be the default one.
- there's some sort of priority number for each interface, but i guess this will be overrided by the default interface setting from pervious point
- lwip will always look if there's a interface having an ip in the destination-network and use this interface (like in most other ip stacks, but that's not routing, and lwip has no routing)
- this could be the key to get the wg-tunnel-data that should take the default-route via the lte/gsm_modem connection: lwip seems to allow to bin a outgoing socket to a interface.
So my theory is: set wg-tunnel-if as default (or use the priority). Packets that have a destination ip that is unknown should go into the tunnel. (aka "default route", but we have no routing here...) And the tunnel-packets should be sent through the lte/gsm_modem interface, and that might be solveable by binding the wireguard-outgoing socket(s?) to the lte/gsm_modem interface.
But this is all theory so far - i don't have a esp32 with simxxxx here, only on the remote location, so this will take a while. but i can update this issue with my findings, and in case the idea i have works, this might end in modifying the wireguard code here as well to add a begin/initializer that allows binding the outgoing tunnel-sockets to another netif.
regarding your last paragraph (porting esp_wireguard to esp_netif) - but even in that case, there's no routing in lwip and in my scenario the wg-tunnel must be forced to go the gsm_modem "route" somehow while having the "default route" on the wg-tunnel, so everything like mqtt,... that is used goes into the tunnel.
@smartinick great findings. as Issue #33 is not fixed, try esp-idf
v4.x if you want to go further. v5.x will not work.
Hi, I succefully run esp_wireguard with v5.2.2 and esp_modem (sim700g) to do that you need to:
- enable LWIP_PPP_SUPPORT as suggested by https://github.com/trombik/esp_wireguard/issues/33#issuecomment-1568503651
- change wifi hardcoded ifkey "WIFI_STA_DEF" to "PPP_DEF" at this line: https://github.com/trombik/esp_wireguard/blob/5f9d5a0ec7431fcac362ed67576c3fa32d3bcc34/src/wireguardif.c#L914
That's a great find. I'm still in a difficult situation. If you have a patch, it would be more than welcome.