lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3cde6506-821c-43f9-a53e-4ddddbb90f79@frank.fyi>
Date: Sun, 13 Apr 2025 22:56:57 +0000
From: Klaus Frank <vger.kernel.org@...nk.fyi>
To: jon@...def.net, netdev@...r.kernel.org
Subject: Re: Is there a way for ifconfig to return wan ip addresses?

Hi,

the short or the long answer?
The short answer "yes, but no".
Also your router may not even know your wan ip either (in case of CG-NAT).

The long anser:
It is quite complicated as there are way too many "standards" for this 
and none of them is universal. Basically you'd have to try a bunch of 
different approaches and somehow also figure out what to do with 
conflicting information. I'll provide them as a kind of list as maybe 
one of them alone (without having a truely universal algorithm for it) 
may be enough. Further I'm going to assume you mean for IPv4 as in an 
IPv6 network you'd already have your GUA(s) on your interface (well, or 
at least on a interface, not necessarily the upstream one but anyway 
thats a different topic).
* RFC 7788 "Home Network Control Protocol"
* RFC 7618 "Dynamic Shared IPv4 Allocation"
* RFC 6886 "NAT Port Mapping Protocol (NAT-PMP)"
* RFC 6970 "Universal Plug and Play (UPnP) Internet Gateway Device - 
Port Control Protocol Interworking Function (IGD-PCP IWF)"
* RFC 7291 "DHCP Options for the Port Control Protocol (PCP)"
* RFC 7225 "Discovering NAT64 IPv6 Prefixes Using the Port Control 
Protocol (PCP)"
* RFC 2663 "IP Network Address Translator (NAT) Terminology and 
Considerations" See address binding and e.g. RSIP, RSA-IP, RSAP-IP in 
Section 5
* RFC 3022 "Traditional NAT" Section 5.3 says your border router may 
allow some hosts to use public IPs and may (without mentioning how) 
advertise information (like the public IP) from the public link to them.
* [RFC 5597 "NAT DCCP Requirements" Section 1: "Also, a separate, 
unspecified mechanism may be needed, such as Unilateral Self Address 
Fixing (UNSAF) [RFC3424] protocols, if an endpoint needs to learn its 
own external NAT mappings."]
* RFC 3424 "IAB Considerations for UNilateral Self-Address Fixing 
(UNSAF) Across Network Address Translation"
* RFC 2766 "Network Address Translation - Protocol Translation (NAT-PT)"
* RFC 2765 "Stateless IP/ICMP Translation Algorithm (SIIT)" can be 
parsed out of the statelessly translated IPv6 address interestingly that 
RFC also mentions "Determine when (...) needs to be allocated and then 
allocation needs to be refreshed/renewed" but it doesn't mention how to 
do this.
* MIPv6 RFC 3519, RFC 5944, ...: But doesn't specify how the 
implementation looks like, just that it is needed. "In the presence of 
NATs, an improved solution would require the ability to discover the 
translations done by each NAT along the route"
* RFC 3027 "Protocol Complications with NAT" Section 2.3, and 5
* draft-ermagan-lisp-nat-traversal-20 "NAT traversal for LISP" also 
specifies a way to discover the public IP
* Host_Identity_Protocol RFC 9028 and RFC 5207 Section 4
* RFC 8445, RFC 8489, RFC 5245, RFC 8656, RFC 5128, 
draft-rosenberg-mmusic-ice-nonsip-01 aka. ICE, STUN, TURN, WebRTC, SIP, ...
* RFC 5853 "Requirements from Session Initiation Protocol (SIP) Session 
Border Control (SBC) Deployments" Section-3.4.2
* RFC 2205 "Resource ReSerVation Protocol (RSVP)" + RFC 6780 "RSVP 
ASSOCIATION Object Extensions"
* RFC 7599, RFC 7598, RFC 6145 "MAP-T"
* RFC 7597, RFC 7598, RFC 2473 "MAP-E"
* RFC 6346 "The Address plus Port (A+P) Approach to the IPv4 Address 
Shortage"
* RFC 7600 "IPv4 Residual Deployment via IPv6 - A Stateless Solution 
(4rd)" by reversing the address mapping or if the CE supports it using 
one of the other approaches.
* TR-069 CWMP (WAN/ISP side)
* TR-064 LAN side
* "curl -4 https://ifconfig.co"


But if you're asking for advice on how to handle this I'd say:
1. Try to go IPv6-first and/or IPv6-mostly, just way less headach and 
better performance.
2. Where not possible either go the kinda radical way and use tor or i2p 
as an overlay and have them deal with nat traversal or if that is 
undesirable use something like libp2p or a webrtc library.
3. If all of that doesn't work try to connect to and proxy through a 
TURN server.
4. If that also doesn't work try to connect to a HTTP(S) proxy that 
supports HTTP-CONNECT tunnel
5. (no experience so far, but is newer and could work in some 
environments) the *-over-QUIC RFCs (RFC 9250, RFC 9221, RFC 9000, RFC 
9220, RFC 9484, RFC 9298, RFC 9297, and ongoing drafts: 
https://datatracker.ietf.org/wg/masque/documents/)

Tbh I personally when neither going IPv6-only or working around the v4 
NAT with e.g. a VPN isn't an option would just use tor, i2p, libp2p, or 
Yggdrasil as my overlay and let them deal with the hard parts. Basically 
I'd use e.g. the Tor Projects Arti project as my transport layer 
https://gitlab.torproject.org/tpo/core/arti Tor and i2p have the added 
benefit of being fully End-to-End encrypted and the endpoint addresses 
being unambiguous and cryptographically ensured.

Also just a note if you're leaving the SOHO and SMB environments and 
also having to deal with enterprise networks then you basically don't 
have any way to autodetect this as there are ofte multiple (literally 
countless) nats to different public IPs depending on destination, 
protocol, or even network saturation. You basically have to let the 
admin/user provide one manually.
(And side note, I also have already used it to link stuff together 
without a centralized public server)


Sincerely,
Klaus Frank

On 2025-04-13 10:51:29, Jon wrote:
> Maybe by interfacing with the router?
>
> You can somehow send some kind of query to the router using router protocols, and it’ll process a return packet with the wan ip address I think, per wan ip address attached to the router
>
> Or you can flat out make a standard for all routers to adhere to when returning wan ip addresses, along with others stuff like live latency checks or some kind of network security module
>
> Or someone awesome can implement some kind of protocol or handshake method for linux router distributions to return the wan ip address directly from the linux router
>
> I think my packet thing will work
>
> You can send a packet through the lan network, and it should return the wan ip address, I think, just through multiple layers or something



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ