RPi associating two IPs with its one and only wifi interface

Mea culpa, I thought I did.

Here is today's output... but I have long since gotten rid of that extra IP, so I'm not sure if this is at all interesting:

Should it happen again I'll capture this output in case it helps find the source.

Jim

NAT does not offer any protection. The reason that a typical domestic NAT-equipped router protects you from inbound connections is that it has a firewall as well.

(Getting a packet addressed to your internal addresses to your external interface is inconvenient for many attackers, for sure, but striaghtforward for your ISP or anyone who can hack or coerce them.)

I've not encountered anything that's more difficult in IPv6 than in IPv4. I'm certain that IPv6 works just as well and as reliably as IPv4; after all, it's been in global-scale use for many years now, so all the issues have been solved. But there's always scope for something to go wrong, like in the example I quoted earlier where there was an IPv6 interface that didn't previously exist, and configuring it (which was no more difficult than the original IPv4 config, which was done so long ago that everyone had forgotten it) simply hadn't been done. Since everything mainstream now defaults to IPv6, there were two fault symptoms, depending which browser and OS were in use:

2) The site was reached, but only after a delay.

Nothing about it was a problem of IPv6 per se.

I'd be interested to know what "policy routing rules based upon a host computer IP" you're using. My router runs OpenWRT. Everything gets its IPv6 address via DHCPv6. The traffic rules pick up the device by name, so, if the IPv6 address changes, the rules change automatically to match.

David

I use Ubuntu, which gives itself two routable IPv6 addresses. One is always the same (good if you have an internet-accessible server) and the other is new each reboot (good for privacy). Maybe it's the same for you?

David

Interesting that you have anything in that directory at all; the one on my Debian Unstable system is empty.

This symlinking to /dev/null is called “masking”. It explicitly disables those service entries (originals present in /lib/systemd/network in this case) so they cannot be (easily/accidentally) enabled.

Depends on what you see your role as. I make part of my living as a Linux sysadmin, so naturally odd behaviours on my own systems would tend to be a matter of professional interest.

No, its more that it imposes a different discipline, And that has to be learnt, taught and implemented.

And that takes time, costs money and always has gotchas.

Which is why most people (consumers and even businesses) are still running V4 + NAT....

Linux has had a fit about the naming of interfaces. wlan seems deprecated.

Not sure a neutrino would do it. A muon however...

How? Genuine question.

In general, I'm not claiming IPv6 is more difficult. However, I have 30+ years of dealing with and solving the problems of IPv4. Switching to dual stack IPv6 is introducing new problems, which I need to understand and solve.

The reason I was looking at IPv6 was to solve some poorly understood problems I appear to have with a new VoIP SIP provider.

But in practice, I am having IPv6 problems. Not caused by IPv6 itself, but apparently by third party misconfiguration. It is no good IPv6 being good, or my routing implementation being good, if in practice I'm banging my head against third party problems.

At this stage it is quite possible I have misconfigured something, but it takes a lot of effort for me to understand each problem, so I discuss my experience in this public forum to gauge other people's practical experience.

I use permanent VPN tunnels to access the WAN, something like NordVPN. Some LAN services I specifically want to route through the VPN, some I specifically want to route over the standard WAN. One way I have traditionally done this is to using a pfSense router to use a service internal LAN IP address to decide which external gateway to route over. Other people might do something similar using VLANs, but my switch hardware strips VLAN tags.

For the avoidance of doubt, I'm relatively naive w.r.t. networking. I just knock up the first thing that works, rather than do something technically orthodox.

Yes, I'm using an Ubuntu derivative. That is what I had. I had the IPv6 address DHCPv6/RA assigned, plus there was a temporary one. Most external connections to the WAN went over the temporary one. I guess this is to not expose my permanent routable IPv6 address, the one I'm likely to have open ports on.

AIUI, the temporary IPv6 address is preferred for one day, but hangs around for 7 days.

Same as routing any other packet. Make sure there’s an appropriate routing table entry for the customer addresses on the ISP’s customer-facing router (and whatever intermediate routers there are between that and the attack source), then call socket/connect/write.

The question is then what the customer router does with it.

• If it follows the strong end system then the packet is discarded before NAT even comes into the question. Linux follows the weak end system model by default, so this possibility doesn’t apply to Linux-based router unless someone has taken the trouble to change its behavior somehow.

• If there’s a basically competent firewall on the customer router then the packet is discard by that.

• If there’s a NAT then it gets to look at the packet, but it won’t match any of the rules that enable translation, so it will not be modified at this stage.

• All that’s now left is normal routing, so the packet passes on to its destination on the customer network.

Ah. I misunderstood your original post. Sure the ISP can send an internally addressed packet to your router. If it wants to lose its customer base.

But will that get forwarded along?

I can't believe that my router would accept arbitrary packets with an internal destination address on its external facing port...if the destination is not in its tables, it will be automatically discarded...

• The police turn up with a warrant and inform you that if you don’t help them break into a certain customer’s network, you will go to prison.
• The mafia turn up with a gun, and inform you that if you don’t help them break into a certain customer’s network, you will be shot.
• A teenager who follows full-disclosure exploits the latest zero day to break into the ISP’s network, and from there to as many customers as they can reach.
• An ISP staff member suspects that a friend who happens to be a customer is having an affair with their wife. Overwhelmed by jealousy they decide to attempt to hack the customer’s computers.

You can probably imagine more scenarios.

It probbaly doesn’t: it might use the strong end system model, and if not it might have a firewall preventing it. But whatever its configuration, it’s not NAT that stops it.

The internal network destination address _is_ in its routing table. That’s how it sends legitimate packets back to the internal network (e.g. when an internal host pings the router).

On my router:

$ ip route show|grep 172.17.207.0 172.17.207.0/24 dev br0 proto kernel scope link src 172.17.207.1

(172.17.207.0 is my internal network.)

But not its port. And not in its NAT table,

The essence of NAT is that the originating port cannot be accessed directly.

And that *everything* gets translated, There is no concept of 'allowing some s*it through even though it's not in my NAT tables' beyond theoretical.

Whether that is a feature of NAT or a firewall, is semantics, but *in practice* it is not a security risk.

If the police want to examine my server, they simply knock on the door with a warrant. No matter what protocol is on the interface

Irrelevant.

I literally did the experiment, you can see the results in the link posted earlier.

I didn't (explicitly) put those there. I don't know whether they were put there in the installation image or whether some initial configuration I did added those.

I don't think "Linux" has had a fit about naming of interfaces. All of my machines (RPi and otherwise) have "wlan0". But I have seen more exotic names on some distros.