Second IP Address - Everything works except for one program/PF
-
@steveits said in Second IP Address - Everything works except for one program/PF:
@lasergecko With 1:1 you can control access via firewall rules. Otherwise everything is forwarded...80, 443, 53, 22, etc.
Ah, gotcha (I think). So, I don't need to set Port Forwards in addition to 1:1, I can just handle access with Firewall Rules...since it's
1:1 also handles outbound NAT, per the doc page I linked. So it kind of depends what you want. You can use a forward and set your own/hybrid outbound NAT. Outbound NAT makes outgoing traffic from that LAN IP use the alias IP instead of the WAN IP.
I'm fine with the outgoing packets showing the Static IP.
re: the /32 subnet, that is "my IP and nothing else"...what is the mask on the primary IP?
The mask for the static IP on the Interface is /28.
Can you Diagnostics/Ping something on the Internet from that alias IP? I would expect not...
I can ping the Dev computer from home, but the packets are being caught by "Default deny rule IPv4".
No problem pinging from the Dev computer:
(Screenshot taken from home, via Screen Sharing to the FQDN.) -
@viragomann said in Second IP Address - Everything works except for one program/PF:
Ensure that the host name resolves to the internal IP correctly on the other LAN devices.
This should have nothing to do with an additional public IP as long as it's not involved at all. Using a host override, it's not.
Yup, that works just fine:
I thought I had checked that, but wasn't completely sure since I hadn't pinged it so I was just relying on the fact that the Web UI timed out with "unreachable". Good call. Thank you for the sanity check.
These pings and the local browser requests aren't showing up in any Firewall logs (since they're not from Cox interface).
-
@steveits I updated the mask to /28. No difference.
I got the full details of the second IP (previously, the person only sent me the IP address) and the Gateway is different than our previous IP. Could that make any difference?
-
@lasergecko said in Second IP Address - Everything works except for one program/PF:
the Gateway is different than our previous IP
Not sure what to make of that. Are they routing that new IP to your WAN IP? If not since it has a different gateway I would think that would need its own interface...? Otherwise how will it be able to talk to the Internet...
BTW, I meant to comment earlier...2.4.4. is several versions old at this point. Not that it will make a difference in the routing but when you get it straightened out you should consider upgrading.
-
@steveits Yeah, I thought that was odd myself. Our regular contact was out of the office, so we had to call and get the info from some random tech support person. I'm going to verify the info I was given.
Maybe it's coming out the 2nd Ethernet port on the modem?
Our hardware is a WatchGuard Firebox something, so I wasn't sure if it could be upgraded without causing issues since pfSense was hacked onto it. It's one of the things that I've always meant to get around to investigating, but there aren't enough hours in the day...until something like this happens.
It's one of those things that you think ought to work just fine, but then again, I thought that by just following the tutorial, I'd be done with this in an hour, too. :)
-
@lasergecko said in Second IP Address - Everything works except for one program/PF:
It's one of those things that you think ought to work just fine, but then again, I thought that by just following the tutorial, I'd be done with this in an hour, too. :)
That shouldn't be a big deal at all, but it needs proper details what you get from the provider.
-
@viragomann Confirmed from a phone tech because it's not actually in the account info. (Thanks, Cox!) As suspected, it is not on the second port on the cable modem.
First IP xxx.xxx.xxx.134 Gateway xxx.xxx.xxx.129
Second IP xxx.xxx.xxx.171 Gateway xxx.xxx.xxx.161It turns out that the macOS Firewall was blocking that program even though it should not have been. I can now access the web interface, but the two machines cannot connect reliably.
They can both ping each other using the FQDN, local IP, and ZeroTier. Only the Production server can hit the secure Dev WebUI consistently. Dev is the target of the Second IP address.
Does that have anything to do with the second gateway?
Does it make sense to make a LAN based rule to force all clients to use the .129 gateway?
-
@lasergecko I am a bit confused because Virtual IP Addresses don't have a gateway setting. I would think to have that work you'd need to have a second WAN interface for that IP, and have traffic from the web server route out that IP. Basically, have two WANs but use them independently.
The more normal way is to allocate a block of 8 IPs (5 usable) and you can use Virtual IPs for the additional 4. However if they didn't allocate you that whole block (.128-.135) and some other client is using IPs in it then you'd have to change your WAN1 IP to a new IP/subnet they assign.
-
@lasergecko said in Second IP Address - Everything works except for one program/PF:
First IP xxx.xxx.xxx.134 Gateway xxx.xxx.xxx.129
Second IP xxx.xxx.xxx.171 Gateway xxx.xxx.xxx.161That seems strange. Usually when getting a second public IP from the same provider, it is routed to the primary IP from outside. And there is no need to state an additional gateway, all traffic is passed over a single gateway, even if the second IP is outside of the subnet of the first.
However, this depends on the configuration of the ISP devices.You can easily test the communication by using Diagnostic > Ping on pfSense. Select the second WAN IP from source drop-down and enter a public IP to ping like 8.8.8.8.
I can now access the web interface, but the two machines cannot connect reliably.
What does this mean?
From outside, from LAN?
Maybe you can give better details, what is working now and what is not. -
Well, it's good to know that something is different and odd with this setup and it's not just me. I will call back to see if they can change it to the same gateway to see if that makes any difference. The data is definitely coming in on that singular internet tube. :)
Here's a photo of the connection matrix that denotes what works and what fails. For that software to be able to work correctly, they need to be able to access the secure FQDN.
The Apple Firewall is disabled on each machine.
The Dev server is the one with the second static IP.
It's soooo close to working. :)
-
@lasergecko said in Second IP Address - Everything works except for one program/PF:
Here's a photo of the connection matrix that denotes what works and what fails.
This doesn't show, if it's working or not from LAN or from outside.
For that software to be able to work correctly, they need to be able to access the secure FQDN.
Seems also that it needs TLS encryption. So you need an SSL certificate matching the FQDNs on both servers. Did you add a specific to the dev server?
-
They're both working perfectly from outside the LAN. Both have their own SSL. (I didn't include that data because I created that spreadsheet to keep troubleshooting this issue straight, hoping to see a pattern.)
I've deployed this software many, many times since I used to work for the company that sold it. If the servers were at separate sites or AWS instances, everything would be just peachy. It works just fine using FQDN from my computer on the LAN, at home, tethered to my phone.
For some reason, it looks like pfSense is prohibiting just Dev from reaching the Prod FQDN, but just via that method.
Dev's hosts file is stock, btw. so that shouldn't be causing any issues.
-
@lasergecko said in Second IP Address - Everything works except for one program/PF:
For some reason, it looks like pfSense is prohibiting just Dev from reaching the Prod FQDN, but just via that method.
The only one part where pfSense can affect the FQDN is at DNS resolution, if you use the DNS resolver. But since you say it resolves correctly, I cannot think of any issue with pfSense.
As I got you, the only problem is to access the dev server from within the same LAN. However, this traffic doesn't doesn't pass pfSense, when the host name resolves the the servers internal IP address.
So I think, you should look for the reason on the server itself. Maybe its firewall is blocking access from LAN, maybe the server have set a wrong network mask so that he is sending responses to the gateway.
Possibly you can sniff the traffic to find out more about what's going on.