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.

@bob-dig Thanks!

@johnpoz

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 ?

@bigunit99
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:
interface: LAN
Protocol: TCP or whatever you need
Source: any
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

@usereric that is works at all is surprising because your 1st hop is 192.168.1/24 and your second hop is also a 192.168.1 address.

If your ISP device is going to hand out 192.168.1 addresses, you should set your pfsense lan to be something different say 192.168.2/24

ATT fiber might have a IP passthru mode.

@lburns Just read the first reply. It explains how to do it.

@johnpoz OK I understand, thanks. Yeah, so a traceroute to 8.8.8.8 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.

MY misstakes, tested from the wrong machine. Everything is working fine :P

@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.

@viragomann

So I just took another look and I think I can confirm that the packets do go back over the ISP network (because I see that the packets try to go through my ONT in both directions) - thanks

Yes, I noticed this and it's quite strange to me. I'd had ideas for reasons if it would behave the other way round.

The main reason why I tried TCP in the first place was because I saw this post on serverfault.

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):
65d9f08d-212c-4fea-907e-4511765fc9a7-image.png

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):

0b611736-20e8-4962-833d-87b604ed0e08-image.png

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):

3db70683-6491-4481-920d-ba53f95243d0-image.png

thanks dear its working now. 👍

@bibawa said in Redirect internal Ip > External:

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.

@johnpoz
sorry sir, I forgot to give the example, but the topology I made remains the same as drawn, it's just that I recreate the VM with a different IP.

No sir, I installed the IDS/IPS on pfsense, and Snort/Suricata will secure the network (intrnet1), namely the web server itself.

I've added a topic to the link you provided, please respond back, sir

@sensewolf said in Need to convene the brain trust on DNS rebinding issue:

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.

Huh??

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
private-domain: "plex.direct"

And now it can find the rfc1918 address. That it got from public NSers out on the internet

@pop69er said in Using external ip/domain to access lan computer inside lan:

the domain address is jer-bear.ca.

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.

@mleighton

Sorry, im just new here. Im using PFsense/NETGATE