Hi Clive. You don’t need a /29 subnet for any of that. Unless it’s issued/negotiated free then you may be paying your ISP for something you don’t actually need. It doesn’t appear your actually using any more than one public IP address on your setup.

The /29 is standard and inclusive from A&A.

My understanding is that for VoIP it is best not to use NAT, and using the /29 for VoIP would be better, problem is all the "hows".....

Cheers!

To be fair VoIP works perfectly fine for most folks on a simple NAT connection that don’t have a /29 or the like at their disposal or the wherewithal and networking to exploit it.

Unless of course you have dozens or hundreds of employees behind the router. It’s a different ball game. But for home meh you really don’t need it.

Actually it isn't an either or situation.

You could use some of the /29 addresses by having a network with direct assignments to specific hosts or services.
Logical choices are any services which inherently use either large ranges of port numbers or unpredictable port number and could benefit from not having the addresses or port numbers translated.

Examples can include VoIP PBX servers (operating multiple extensions on the internal network), legacy FTP servers, media servers, or games consoles as long as they are intended to be Internet facing.
They are still behind your firewall so it doesn't mean they have to be left wide open.

If there is a firewall policy between this network and both the Internet and your private address space then this can also be classed as a DMZ network (not a DMZ host).

At the same time you could assign (reserve) one of these public addresses to continue to use NAT from your private address space. The 81.xxx.xxx.6 address is as good a choice as any for that.

It's a type of source NAT, as is NAT masquerade though there are slight differences:

* "Masquerade" means source IP of traffic from your private addresses (e.g. 192.168.1.x) gets translated to an IP actually assigned to an interface on the router (i.e. the WAN interface IP). When stuff on the Internet replies to the WAN address, the router checks an outgoing table and translates it back to the original private IP.

* Your source NAT will work the same except the source IP of traffic from your private addresses now gets translated to 81.xxx.xxx.6.
When stuff on the Internet replies to this address, the router checks the outgoing table and translates it back to the original private IP, otherwise if it wasn't replying to .6 but say real .y, it just delivers (routes) it back to the 81.xxx.xxx.y address on the "DMZ" network.

Other differences: there is not actually a computer set with the 81.xxx.xxx.6 address so it's only used in the NAT mapping.
Also note that nothing is replying to the WAN address of the router unless the traffic originated from the router itself, say a DNS lookup or an update check). This is correct, its main job is now to link your router to your ISP rather than to pretend to be everything inside your network.

You'd need to look at the outbound or source NAT rules on the router to see this is the case.

In summary you would have 2 networks internally behind the router, one with private NATed addresses and one with public routed addresses, and ideally these should sit on separate interfaces of the router (so at least 3 independent interfaces including WAN).

The fact that you saw 81.xxx.xxx.6 addresses with the ISP supplied router may mean it was already setup somewhat similarly.

Edited by prlzx (Tue 25-Jan-22 01:06:07)

Sorry if that was a wall of text, much of what I wrote about the routed subnet without NAT applies likewise to IPv6.

The prevalence of NAT has become so embedded in how we think about consumer Internet access that people can find it jarring when thinking about being assigned a routed subnet of public addresses (a /64, a /56 or a /48) that are nontheless internal and behind your firewall, and different from the single IP that only exists for the router itself to talk to the ISP, compared with "faking it" to make that single IP act such that a bunch of private IPs seem to work.

Edited by prlzx (Tue 25-Jan-22 01:12:08)

In reply to a post by prlzx:

Actually it isn't an either or situation.

Indeed not - I have several RFC1918 ranges in use, some of which have internet access via NAT, as well as my 81.xxx.yyy.zzz/27 which is heavily firewalled. (it's a /27 in my case as I have been an AAISP customer for many years).

* Your source NAT will work the same except the source IP of traffic from your private addresses now gets translated to 81.xxx.xxx.6.
When stuff on the Internet replies to this address, the router checks the outgoing table and translates it back to the original private IP, otherwise if it wasn't replying to .6 but say real .y, it just delivers (routes) it back to the 81.xxx.xxx.y address on the "DMZ" network.

Other differences: there is not actually a computer set with the 81.xxx.xxx.6 address so it's only used in the NAT mapping.

The fact that you saw 81.xxx.xxx.6 addresses with the ISP supplied router may mean it was already setup somewhat similarly.

The opposite - 81.xxx.xxx.6 *will* be a real computer - there is a 7th IP in play which is the one associated with the PPP endpoint - that is the one which is most logical for NATed addresses to use as the egress address.

It is because the loan router is NOT set up for NAT that our seafaring friend is seeing it "out" on the internet.

I have to disagree; if I received a real /29 or larger allocation, I would not want to use the router's own WAN interface in NAT mappings, but would rather use an address in the routed subnet.

That way, if the (say) .6 address becomes targeted by scans or more unwanted traffic that doesn't necessarily pose a threat to the router itself nor its PPP connection to the ISP.

Plus that leaves me options to change the nature of the ISP connection or to decide whether I want to place a second router at .6 just to handle the private NAT without needing tell the outside world in either case.

As far as I am concerned the WAN interface IP will just be the PPP with a /32 and routing path to link with the ISP rather than acting as source of traffic from other hosts.

Oh and the Internet will only ever see routeable public IPs anyway* unless it uses Javascript or similar within a page to query the local IP.

(*) assuming the ISP employs anti-spoofing and blackholing traffic to/from RFC1918 as well as anything from the customer whose source doesn't matching their public assignments (which is good practice anyway).

Edited by prlzx (Tue 25-Jan-22 14:17:11)

In reply to a post by Ancient_Mariner:

My understanding is that for VoIP it is best not to use NAT, and using the /29 for VoIP would be better, problem is all the "hows".....

AAISP insist in saying this, but I've been using their VoIP for 2 years with my Virgin Media broadband (single dynamic IP v4) with NAT without issue. I would switch to AAISP for broadband, but I would take an 60% hit in download speed, and 90% hit in upload speed. So no chance

I have an elderly Cisco ATA plugged in to my Asus router, and my Virgin box is in modem mode. Then a basic landline handset plugged into the ATA. I migrated my old Openreach phone number to AAISP in mid 2019..

RE your Cisco ATA. I am using their ATA 191 currently for pre-porting test purposes with an AAISP VOIP number.

Is there any way that you can set up a divert/forwarding for incoming calls to another number if you are away in a similar manner to BT's dial: *21*(phone number you want to divert to)# to set up and #21# to cancel?

The ATA191 instructions suggest using #72nnnnnnnnnnn# to set up, but all I get is the beep-beep tone after I have keyed as far as #72

I guess that I could set it to ring my mobile at the same time. I will test that out to see if I get charged for that call if I don't answer it.

Cheers!

The Cisco ATA is incredibly complicated. I wouldn’t be surprised if one of the defaults is not sending the sequence to the server but interpreting it locally 🤨