@steveits Figured it out. The lan is the "wan" of the Unifi gateway device that runs the internal network. NAT was enabled there so everything coming to the pfsense lan was natt'ed... disabled that NAT and everything started working.
@viragomann aaaaaah ... that could be the prob ... sure there are routes pushed by the openVPN server and they are already listed in the routing table of our pfsense (pfsense indeed is the openVPN client in this cas) ... so i will click that "dont pull routes" than probably reconnect if its not done by its own ...
so now the tunnel_destinations dont appear in the routing table anymore and ALL clients will go via default WAN to those ips ...
then i've added a rule to LAN which again put in the 2 conditions allowed_hosts and tunnel_destinations using vpn interface
Virtual IPs and Aliases are basically different things at all.
Virtual IPs can be assigned to interfaces as additional IPs. In your case type "IP alias" is the best to be to use here, but also others would be possible, e.g. CARP.
If they are not CARP themself, they have to be hooked up on the primary CARP VIP for the failover to work.
Aliases of type IP in this case is an independent array of IP addresses. It doesn't matter if these are assigned to an interface or not. They can be used in firewall or NAT rules.
Normally, that's a good thing, placing a final block all rule on WAN.
But that rule won't be the final rule, there is another one, hidden, on every interface, and it block everything.
When you create a NAT rule, and you have your own home made block all rule on WAN, then you need to re order the auto created firewall rule on WAN above your own block rule. Otherwise, your NAT rule might be perfect, but .... it will not work fro 'some' reason.
I know, as the same thing happens to me while preparing the NAT demo for you yesterday ;)
( I actually ditched my final block-all rule on LAN so it won't happen again if I have to crate a NAT rule )
@gertjan Hi so actually, the author of this book has some custom scripts on his website. This is to make the process easier for configuring the firewall.
So i went ahead and uploaded a custom script with all the settings i need.
However, my issue now is that in the "status" of "OpenVPN" is never showing as "up". It is either "pending" or "down" or "failed". SeeScreen Shot 2022-09-05 at 11.38.37 AM.png :
Part of the additional instructions is to designate a custom server IP address from my ProtonVPN service. Basically you choose a server from a list on ProtonVPN's site, and then download a file. I was instructed to open it in a text editor and identify the IP address and manually enter it. That way all my internet traffic is being routed through that specific server.
However, in the file looks like this: Screen Shot 2022-09-05 at 11.29.19 AM.png
If i enter any of those full IP addresses, it gives an error, saying its no t a valid address. When i use the root address 126.96.36.199, it will accept it. So i'm not sure if that is correct or not.
In the end, my status on OpenVPN is not showing "up" and thats the end goal according to my instructions.
If you are trying to get to your server from LAN using the public IP address, you'll still need Reflection enabled (see "Enable NAT Reflection for 1:1 NAT"). I would get it working from outside first, then worry about the LAN.
BTW, for 1:1 NAT you don't need to configure Outbound NAT. https://docs.netgate.com/pfsense/en/latest/nat/1-1.html
"All traffic originating from that private IP address going to the Internet through the interface selected on the 1:1 NAT entry will be mapped by 1:1 NAT to the public IP address defined in the entry, overriding the Outbound NAT configuration."
I found this link Multi-WAN and NAT that says you need a separate forward entry for each WAN. It just seems onerous since I have a lot of entries. It would be great if the interface could create the multiple entries at the same time, but then we would manage them as separate entries. It wouldn't seem that hard to add to make this process easier.
The ridiculous thing is that I wanted to use HAproxy (with Acme for certs) to keep all networking inside my PFsense system. I had some difficulty with HAproxy (probably my own fault either with HA or the service setup I was forwarding to)
A great deal of the information I got from the internet said "Nginx" or "Traefik" were the way to go, so I tried Nginx.
I'm going to take your suggestion of packet capture on both sides.
After that I might just shutdown Nginx and return to HAproxy (w/Acme) and try to figure out the proxy/ports.
What type of misconfiguration can cause these issues? I'm actually quite doubtful about my network, because on some parts of network we are using hubs (unmanaged switches). Can improper isolation of vlans be the cause of problem ?
I see, but it’s usually desired to see the origin IP address, to know where the request is coming from.
However, if you don’t care about that you can also masquerade inbound traffic by an outbound NAT rule. You have to add it manually though.
To do so, switch over the outbound NAT to hybrid mode. Then add a rule:
Protocol: TCP or whatever you need
destinations: LAN net or an alias which
includes the desired IPs
destinations port : any or an alias which includes the ports you need
Translation: interface address
@johnpoz OK I understand, thanks. Yeah, so a traceroute to 188.8.131.52 would help the ISP find where it is blocked. Unless they know and are being jerks...because pretty much any router will have security updates.
@lonmarlon Set the hostname to resolve to that public IP...? Or if it is already set, then likely the webmail server isn't set to use that hostname. Unless you've installed a reverse proxy, there's nothing in pfSense that knows what hostname was used. The packet arrives for IP "n" and pfSense processes it.
I don't think the scenario is quite the same, but it's the only thing I've found on the internet that had any semblance to my issue (where the port #s change):
Since you don't provide IP addresses, I'm missing the needed information to investigate.
Here's the previous packet capture of when I tried to connect to the VPN server from within the ISP network (where pfSense WAN IP is 50.x.x.x, the ISP WAN IP is 75.x.x..x):
And here's the packet capture when I connect to the VPN server from an external network (where 207.x.x.x is the IP of the external network):
it's not possible to change the ip address in the code
I find that hard to believe - where did this app come from, written in house and now the writer is no longer with the company?
Should of pointed to fqdn not some IP.
Anyway - assume your pfsense has an IP on this 192.168.6 network? If so then create a vip so it answers arp for 192.168.6.13
Then create a port forward sending the traffic where you want to send it. If the sender is on a different network that routes through pfsense say the client it on 192.168.5/24 for something then you do not need to create the vip.
What I am saying is that pfSense should tell server1 server2's private IP when server1 looks for server2.example.com. But pfSense doesn't.
If you setup a host override for server2, any client that asks pfsense would get that response..
As already stated if your unbound is getting that address from some other NS, and its rfc1918 then it would be a rebind.. You can set the domain example.com to be set as private, and then it would hand the client the rfc1918 just fine..
example of this plex uses a special fqdn to find the IPs of your server, be it public address and its local rfc1918 address..
So you set this domain as private in unbound custom option box
And now it can find the rfc1918 address. That it got from public NSers out on the internet
I don't understand the term "I cannot access my LAN computers from my domain name address".
I have no idea what you mean with "from my domain name address" in this context?
Your outbound NAT rules might not be responsible for this issue, I think. But there are some useless and wrong rules, which you can remove to clean it up.
You can remove the rule numbers: 1, 3, 4, 6 (all WAN rules).
All these rules are also automatically created by pfSense as seen below.
So only the rules for the VPN interfaces are still needed.
As the automatic rules show, you have two local networks: 192.168.10.0/24 and 192.168.15.0/24. But at this time you have only for the first one rules on the VPN interfaces.
If you also direct traffic from 192.168.15.0/24 out to the VPN connection you need to copy the rules for 192.168.10.0/24 and change the source network accordingly.
I update you, I actually rationalized the need ... the 192.168.30.x had to be the gateway for the 172 network, in this way the device that interfaces to the PLC network on 172 could actually route the traffic between the two networks . I really thank you for the speed and availability you gave me in your answers.
@steveits That might just do it, thanks, will have a play with that, never noticed the option below regarding gateway on a rule. Just done some testing and looks good but need to do some more. Thanks for that.