search

trombik / esp_wireguard

WireGuard Implementation for ESP-IDF
Other
184 stars 29 forks source link

Compatibility with esp_modem? #39

Open smartinick opened 1 year ago

smartinick commented 1 year ago

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.

trombik commented 1 year ago

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.

smartinick commented 1 year ago

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).

  1. lwip allows to set a default interface - i think the wireguard-tunnel-if should be the default one.
  2. 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
  3. 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)
  4. 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.

trombik commented 1 year ago

@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.

ceccocats commented 2 weeks ago

Hi, I succefully run esp_wireguard with v5.2.2 and esp_modem (sim700g) to do that you need to:

trombik commented 2 weeks ago

That's a great find. I'm still in a difficult situation. If you have a patch, it would be more than welcome.