Issue with a block of 16 IPv4 addresses
-
@nogbadthebad the issue is here is as before when I was with my old supplier they gave the IP's to me like this
217.13.XX.193 (router/firewall)
217.13.XX.194
217.13.XX.195
217.13.XX.196
217.13.XX.197
217.13.XX.198
217.13.XX.199
217.13.XX.200
217.13.XX.201
217.13.XX.202
217.13.XX.203
217.13.XX.204
217.13.XX.205
217.13.XX.206
217.13.XX.207
217.13.XX.208 (broadcast address)Now Zen Internet issue them to me like this
217.13.XX.193
217.13.XX.194
217.13.XX.195
217.13.XX.196
217.13.XX.197
217.13.XX.198
217.13.XX.199
217.13.XX.200
217.13.XX.201
217.13.XX.202
217.13.XX.203
217.13.XX.204
217.13.XX.205
217.13.XX.206
217.13.XX.207 (router/firewall)
217.13.XX.208 (broadcast address)So when the router is assigned 217.13.XX.207 automatically , its causing issues with my setup. When I try and tell the system it can use the other IP's available to me. It just returns an error basically saying they overlap with the WAN address.
-
@landman16 said in Issue with a block of 16 IPv4 addresses:
So when the router is assigned 217.13.XX.207 automatically , its causing issues with my setup. When I try and tell the system it can use the other IP's available to me. It just returns an error basically saying they overlap with the WAN address.
That router address would be on the LAN side, not WAN. On the WAN side, you need an address that's outside of that block of addresses. This is why we've been asking about what you're being provided. If they expect you to use a router, then they need to provided an appropriate WAN address, which I haven't seen yet. If they're only providing those 16 addresses and no WAN address, then they're expecting you to use them as is, unusual but possible. In that case, you need to configure pfSense as a bridge. Please call your ISP's support and find out what they are providing and expecting you to provide. Until we know that, we're just guessing.
-
@nogbadthebad said in Issue with a block of 16 IPv4 addresses:
It's what @Derelict said 2 posts up, you need to make it clear to Zen you want the /28 subnet routed via a /29 transit network.
Out of interest when you asked for additional IP addresses did you get an option of how you wanted them ?
Looks like they have not routed the block of 16 IP's to me correctly, I have just phoned Zen and asked them if they can route my public subnet of 16 IP's via a /29 transit network. Maybe then I will get a WAN address that is outside of my allocated IP range, so I able then to use my public subnet without it erroring and saying "It cant do it as it overlaps the auto allocated WAN IP. Not sure if this will work, but its worth a go.
Thank you to everyone so far for your help, this has been a tricky one as Zen are/were sure it was my end. Im waiting on a call back. Will be back to update once they have come back to me with the verdict!
-
@landman16 said in Issue with a block of 16 IPv4 addresses:
/29 transit network
Transit networks are commonly /30, though /31 might also be used. With the IPv4 shortage, they're not likely to give you more than you need.
-
Well Zen say "NO!" they do not have the tech onboard their network to route the IPs over a /29 transit network. They are telling me that they are telling me they are only able to route the block of 16 IP's via a Ip frame unnumbered where the wan ip is included within the public subnet range. So not entirely sure what to do here, since they did tell me that they were able to accommodate my needs from the outset. So this is a little disappointing to say the least
-
You’ll need to NAT the addresses then as suggested.
Out of interest is this for business use or home use.
Zen do offer business ethernet and MPLS.
I wish I’d have asked for the 8 public IP addresses that they were handing out FOC when I originally placed my ADSL order with them years ago.
-
@nogbadthebad said in Issue with a block of 16 IPv4 addresses:
You’ll need to NAT the addresses then as suggested.
What's this obsession with NAT? If he has a valid WAN address, then set up pfSense as a regular router. However, if that list of addresses is correct, they're expecting him to run without a router, meaning he configures each server to use that router address as the default gateway, just as you'd configure any computer behind a router. The only difference is the router is at the ISP's and not his location. This is why I suggested configuring a computer with one of those addresses and seeing if it works. If it does, then the ISP does not want a router at his site and pfSense has to be configured as a bridge. It would be really nice if the OP would confirm what arrangements the ISP wants, so we're not speculating. Either way, forget NAT. It's not needed, as he apparently has all the addresses he needs for his servers.
Please remember, NAT is a hack to get around the IPv4 address shortage and should not be used unless absolutely necessary. Based on the info provided, it's not, assuming he has no more than 13 servers.
Incidentally, there appears to be a minor error in that list. Shouldn't the last octet range from 192 to 207? That would be the normal range for a /28, with 217.13.XX.192 the network address and 217.13.XX.207, broadcast.
PfSense running on Qotom mini PC
i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
UniFi AC-Lite access pointI haven't lost my mind. It's around here...somewhere...
-
@landman16 said in Issue with a block of 16 IPv4 addresses:
So this is a little disappointing to say the least
Try using it as a block of "LAN" addresses as I suggested. As I mentioned, that's easily tested by configuring a computer using one of those addresses. As noted above, verify the actual addresses, as there seems to be a discrepancy for a /28.
-
.192/28
.192 = wire
.193 = first address
.207 = last address
.208 = broadcast.That aint right is it.. jknot is correct .207 would be broadcast not last host.
.208 would be the next net
.208/28 -
Yeah .207 is broadcast in .192/28.
If you CANNOT get a subnet routed to you and you CANNOT NAT, then the only other thing you can do is bridge as has been suggested.
Personally, I would 1:1 NAT in that case. Not for any love of NAT, but that would be my preferred way of dealing with this ISP crap unless the application was NAT-sensitive like FTP or VoIP. In that case I would look for an ISP that could deliver the provisioning correct for the application.
-
@derelict said in Issue with a block of 16 IPv4 addresses:
Not for any love of NAT, but that would be my preferred way of dealing with this ISP crap
Why not just use bridge mode and filter that way. Unless I'm mistaken, pfSense can do that, though I have never tried it.
-
I consider bridging to be a last resort.
-
@derelict said in Issue with a block of 16 IPv4 addresses:
I consider bridging to be a last resort.
What's the issue? I'd consider NAT to be a last resort.
-
Mostly because people don't understand what they are doing. Even worse than usual.
I said bridging was an option. I said I would NAT. You have your preference. I have mine. I also said it depends on the application. If it's web servers I really don't care if it's NAT to get around a stupid ISP.
I would actually insist my ISP did it right or get a different one. But I'm pretty far to the edge of the bell curve there.
-
@jknott said in Issue with a block of 16 IPv4 addresses:
@nogbadthebad said in Issue with a block of 16 IPv4 addresses:
You’ll need to NAT the addresses then as suggested.
What's this obsession with NAT?
What is with your hating of NAT?
It is a fact that same that subnet can't exist both sides of the firewall.
I can't even see how this previously worked when the OP said the subnets were like this:-
217.13.XX.193 (router/firewall)
217.13.XX.194
217.13.XX.195
217.13.XX.196
217.13.XX.197
217.13.XX.198
217.13.XX.199
217.13.XX.200
217.13.XX.201
217.13.XX.202
217.13.XX.203
217.13.XX.204
217.13.XX.205
217.13.XX.206
217.13.XX.207
217.13.XX.208 (broadcast address)The only difference is the router address has moved from 217.13.XX.193 to 217.13.XX.207
If the above worked previously with another ISP then 217.13.XX.193 was the LAN address and he had a routed subnet.
-
@nogbadthebad said in Issue with a block of 16 IPv4 addresses:
What is with your hating of NAT?
It's a hack that was created to get around the address shortage. The OP apparently has sufficient addresses.
me that subnet can't exist both sides of the firewall.
Never said it could. However, that proves that the router address provided is on the LAN side, not WAN.
I can't even see how this previously worked when the OP said the subnets were like this:
It will work, if the ISPs expect the computers to use those addresses directly, without a router in between. This is why I said configure pfSense as a bridge. This will allow filtering, without creating a router.
I can't even see how this previously worked when the OP said the subnets were like this
We don't know enough about the original ISP. However, those could be the LAN side, with an appropriate WAN address on the other side. That detail was not mentioned. When I see a list of addresses like that, I see LAN side, not WAN, if an router is to be used. If he had a proper WAN configuration for a router, there would be an address outside of the /28 block. I have not seen that mentioned at all.
How was pfSense configured before? What changes did the OP make? We don't know.
-
@JKnott The only difference is the router is at the ISP's and not his location. This is why I suggested configuring a computer with one of those addresses and seeing if it works. If it does, then the ISP does not want a router at his site and pfSense has to be configured as a bridge. It would be really nice if the OP would confirm what arrangements the ISP wants, so we're not speculating. Either way, forget NAT. It's not needed, as he apparently has all the addresses he needs for his servers.
Im not sure why I should need to change my entire setup just to get it working (sort of). For example the issue with NAT is that I have two mirrored servers with identical software packages on each server node. 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
The only difference is the router is at the ISP's and not his location.
Yes, I think basically my network as it stands at the moment is an extension of their network. They have already told me that they are sending the public ip block to me via some kind of DHCP server setup, or at least this is as far as the tech guy could tell me it works. Where my previous supplier (Spitfire Internet Services) routed them to me directly, I would assume via a /29 transit network setup as I was able to put the range into the router and then just assign the public ip, subnet and gateway directly to the servers NIC card. The reason I moved from them, is over a 2 and a half year period I started to see the connection get worse and worse as time went on (hence the move), towards the end couldnt even stream internet services such as youtube for example.
This is why I suggested configuring a computer with one of those addresses and seeing if it works. If it does, then the ISP does not want a router at his site and pfSense has to be configured as a bridge.
They have kind of already told me this in a round about way. I did state at the point of inception/order that being able to route my IP's the way I have it setup is a requirement. The sales guy said "yes our network can support your request. However conveniently when service goes live and I start having IP range chasing error messages coming out of pfsense they suddenly turn around and tell me their network is not capable of routing the way I had requested from the start of the order process."
It would be really nice if the OP would confirm what arrangements the ISP wants, so we're not speculating. Either way, forget NAT. It's not needed, as he apparently has all the addresses he needs for his servers.
Im not sure what it is you want me to ask the ISP? @NogBadTheBad suggested I should go to them and request the public ip range to be sent to me via /29 transit network. But as stated further up this reply they are not able to do this. The number public IP's assigned to me is perfectly fine. If you could state what it is you want me to ask them and I will drop them a call in the morning and see if I can get anything out of them.
Please remember, NAT is a hack to get around the IPv4 address shortage and should not be used unless absolutely necessary.
This is why I do not want to use it, and can not use it because of the way the servers are setup. I also have a OpenVZ node sat behind pfsense. NAT doesn't work on that, I can get to the host node from the web using 1:1 NAT, but when I try and goto one of the OpenVZ containers virtualised on the node, they don't even appear on the ARP table from the LAN side never mind trying to reach them from the web.
Based on the info provided, it's not, assuming he has no more than 13 servers.
Thats right I don't have anymore than 13 servers, at the moment. I have 10 servers with a buffer of 3 spare public IP's for expansion.
Incidentally, there appears to be a minor error in that list. Shouldn't the last octet range from 192 to 207? That would be the normal range for a /28, with 217.13.XX.192 the network address and 217.13.XX.207, broadcast.
Yes sorry was a typo, apologies there its been a long day trying to get this stupid thing working correctly. I feel as I have wasted two entire days on this, and to be told "out network cant do what you want" when they said "yes our network will support your network without an issue.
Hopefully I have managed to awnser your questions for you, if I have missed anything that I need to ask the ISP in the morning, then do let me know and I will add it to my list to ask them.
-
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) -
This post is deleted! -
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.
