@kruglerd Do you mean by hardcode a 1:1 NAT? Currently I have forwarded all of the ports: 5060+5061 and RTP range from 31000:32000 I have tried it with a fritzbox which forwards all the ports to the pfsense and I have tried a modem and setup pppoe on the pfsense. Both connections type I received the same error

@uglyxiaodi18 said in private network VM Unable to access public IP address: VM in private IP : 1.1.12.1 VM in private IP trying to access public ipv4 : 1.1.22.1 None of these IPs is private at all. However any VM in the private network is not able to access 128.199.117.134:80 If you want to access server, which the public IP is forwarded to, enable NAT reflection in the NAT rule. By default the NAT rule is only applied to the stated interface. NAT reflection applies it to the other interfaces as well.

@johnpoz Unfortunately no, but I ordered that mikrotik switch. Looking at compatible transceivers now as well. I'll be back on site before too long and can switch things over.

@viragomann Thanks. I will try this ;)

Outbound NAT was the key, thank you kindly. I added an Outbound NAT for the WAN interface, with the Source set to Network (172.16.81.x). Translation was set to Address = Interface Address.

@johnpoz hello sir actually just an example i quoted 30/8 but my ip actual settings belong to the rfc1918 standard i use 172.16.0.x for my pihole ip and at the moment its working i added rules from my office lan destination to pihole address, anyway thanks to you and someone input hearing about my concerns. thanks

@steveits I think that's exactly what I was up against. This is a production machine, and I didn't want to experiment too much. I'll be installing the Netgate hardware during one of the upcoming long holiday weekends, and expect that will go well. PfSense has always been bulletproof. The hardware, on the other hand (my hardware- not Netgate's) has had occasional issues. Thanks again, Steve!! Peter

@RobH-0 my apologies I have been away. Here are the screenshots [image: 1663878377390-wan.png] [image: 1663878377312-192.png] [image: 1663878377226-wan_rules.png] [image: 1663878381817-0lannet.png] [image: 1663878381733-10gib.png] [image: 1663878381648-lan_rules.png]

@johnpoz Many thanks ! thats perfect. Alain

@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 et voila ... seems to work =) thanks @viragomann & @Bob-Dig

@steveits That was it, i forgot to add the www one. Thanks mate, truly saved me alot of hassle.

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

How many clients in the 172.16.81 network need to access the 10.1/16 ? If it's not many, why not just use a static route for them, and they connect using the real destination IP.

@georgelza said in pfsense and Synology port forwarding: below a block all. 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 )

System>Advanced>Firewall & NAT Firewall Maximum Table Entries=10000000 Firewall Maximum States=300000 pfBlocker no longer preventing completion of Filter Reload