Issue with a block of 16 IPv4 addresses

landman16

this is how I had it setup previously with Spitfire and it worked perfectly.

217.13.XX.192 (unusable)
217.13.XX.193 (assigned to the router/firewall by me)
217.13.XX.194 (Physical Host Node 1 - OpenVZ)
217.13.XX.195 (Virtual Server 1 - OpenVZ)
217.13.XX.196 (Virtual Server 1 - OpenVZ)
217.13.XX.197 (Virtual Server 1 - OpenVZ)
217.13.XX.198 (Virtual Mail Server 1 - OpenVZ)
217.13.XX.199 (Virtual File Server 1 - OpenVZ)
217.13.XX.200 (Virtual Application Server 1 - Mirrored with Virtual Application Server 2 - OpenVZ) ——— This is where NAT would fail even before the issue with 1:1 NAT doesn’t like virtualised instances
217.13.XX.201 (Virtual Application Server 2 - Mirrored with Virtual Application Server 1 - OpenVZ) ——— This is where NAT would fail even before the issue with 1:1 NAT doesn’t like virtualised instances
217.13.XX.202 (Media Server)
217.13.XX.203 (NAS Server)
217.13.XX.204 (Buffer IP: 1)
217.13.XX.205 (Buffer IP: 2)
217.13.XX.206 (Buffer IP: 3)
217.13.XX.207 (broadcast address / useless to me)

NogBadTheBad

This post is deleted!

JKnott

I have to wonder about your understanding of networks. With both ISPs, you do not appear to have a separate WAN address and what you are now saying indicates this to be true. Your issue with licences has nothing to do with this, other than pointing out one way that NAT is failing you.

As I have mentioned, NAT is a hack to get around the IPv4 address shortage. In the process it breaks things. For example, years ago, some FTP clients wouldn't work with it. These days, things like IPSec authentication headers don't work at all. Other things, like Voice over IP and some games require using STUN servers to tell the other end of the connection what the real IP address is, rather than the NAT address. Then firewalls have to be able to manage whatever services are passing through NAT to ensure they work. Not all are a simple address/port remap. Also, some people running VPNs may run into address conflicts, when the subnet address is the same at both ends. There are many reasons why NAT should be avoided.

The first thing you have to do is get the network working properly, without setting up VMs on the same address etc. Just set it up and ensure you can configure a computer or server on each of the addresses. Pick an address from the list and use static config. Use the assigned router address for the default gateway. If that works, then the network is set up properly for your address range. Now you can start worrying about your VMs, licences, etc.. However those things are beyond pfSense. As I mentioned, pfSense can be configured as a bridge and the same filter rules apply as with a router. When you do that, you probably want to apply one of those addresses to pfSense so you can manage it, though you could set up another interface, with an address outside of your block.

BTW, VMs should behave just like real hardware when it comes to networking, if set up with a bridged adapter. I run Oracle VirtualBox, where I have a choice of bridged or NAT adapters . If you're using NAT for the VMs, this might be the cause of the licence issues. However, that is beyond pfSense.

Bottom line, keep things simple by going one step at a time and seeing where the problems pop up.

Derelict

So you had a routed subnet with Spitfire and now you have a /28 on the WAN interface with Zen.

Im not sure why I should need to change my entire setup just to get it working (sort of).

Because your new ISP isn't provisioned the same as the old one. You have addresses on the outside interface and nothing left to put on the inside. Spitfire gave you provisioning that matched what you needed. You did not buy the same thing from Zen. Not pfSense's fault there.

Each node has two separate licence codes that are assigned to two separate public IPs. The issue with NAT is that the servers behind pfsense are issued with local IPs when 1:1 Nat is being used, and when they send the call-backs out to the licensing servers of the software vendors, it sees 2 servers on 1 IP (The WAN IP) and as soon as the licencing servers detect this, automation takes over and they think its some kind of licence abuse, and suspends my licence and both servers stop working correctly. This is just one example why NAT wouldn't work with my setup

No, you can make the outbound connections appear as different addresses. That's what 1:1 NAT does anyway. Outbound connections will be NATted to the 1:1 for that server on the outside.

landman16

Looking at Zen’s own support documentation it looks like they offer two types of transit networks

Routed Subnets and NAT Subnets

https://support.zen.co.uk/kb/KnowledgebaseArticle.aspx?articleid=10134

So I really would love to know why they are saying they Carnt do it since thier own support documentation says otherwise

NogBadTheBad

Maybe they only do it over ethernet or mpls.

landman16

@nogbadthebad I will ask them that question Monday morning before I put in my cancelation request

bigsy

@landman16
I have a /29 from Zen. In my current setup, pfSense manages the PPPoE connection and any servers are on a 1:1 NAT behind it.

I've previosuly set it up differently. If you have a router that supports Zen's 'routed IP' service, you can put the servers on it like this.

x.x.x.0/29, router address x.x.x.6

xDSL router(PPPoE, IP x.x.x.6)------firewall(IP x.x.x.1)-----LAN
		|	
		|
		|
   servers (IP x.x.x.2-x.x.x.5)

I think this is what @JKnott suggested above. Of course that keeps pfSense completely away from the servers and it uses an additional IP address for the firewall WAN IP address.

landman16

Ok been on the phone with a fella called Ben from
Zen for some time yesturday trying to tap/chip away at this issue.

He is asking when we manually configure IP assignment for the WAN interface instead of letting it do it automatically. It’s asking for the following details

New IPv4 WAN address: now we are assuming this is the public ip in the range that I’m told should be assigned to the router

2 Then it asks if I want to turn on DHCP I say “no”

Then It asks for the upstream gateway, this is where it starts to get a bit of a gray area ISP is asking if this is the upstream gateway of Zen or some IP within my public subnet. We did try the up of the upstream gateway for zen and it errors and says not within the Subnet. So we then tried the public broadcast address in the range and while it didn’t error, Internet didn’t come online ether.

What Ben did ask is when we manually configure the wan interface with IPs is it still transmitting the PPPOE data, or as its now static do we have to take additional steps for it to do this?

Derelict

You cannot request a routed subnet from a PPPoE provider. They must be configured to do it.

You give it a username and password, maybe, they take that plus whatever else they have (VP/VC on [AV]DSL for instance) and provision your circuit.

There are generally three attributes used in RADIUS to do this:

Framed-IP-Address - sets your interface address
Framed-IP-Netmask - sets your interface netmask
Framed-Route - tells their gear to route a subnet to Framed-IP-Address

When I designed an ISP the RADIUS server would be configured to reply to the access servers appropriately, based on the provisioning database, and the access servers would send the routing information, if any, to the infrastructure via OSPF. Worked flawlessly.

JKnott

@landman16 said in Issue with a block of 16 IPv4 addresses:

ISP is asking if this is the upstream gateway of Zen or some IP within my public subnet.

Sounds like your ISP needs some tech support that's not clueless. When configuring a router, it's the ISP's gateway. With computers, it's your own, in this case pfSense.