As I did a quick visit the last weekend with our youngest in D2 I can't find any problem even when not having pure NAT. We've played with two PS4s with both NAT Type 2 (not strict/3 but not pure/1 either) without a hitch. Got together, got into PvE/PvP - don't see problems.
If your going to create a port forward to rdp. The destination would be your wan address on port 3390
The redirect IP would be the IP you want to send it to, and the port 3389 (rdp). Keep in mind that rdp can and wants to use UDP as well. Also - the windows firewall out of the box would block all access to rdp from anything other than its local network. you would have to allow for this.
And again I will warn against opening rdp to the public - it is a HORRIBLE idea, Horrible. Even if you change the port. If you did need to do it for some sort of remote help.. Lock down the source to the known IP, or atleast the known network IP range that will be using it.
The secure method of rdp to stuff on your network from remote is vpn.
@viragomann Okay I think im getting somewhere with this using a vlan. Iv set it up. Havent assigned anything to that vlan yet but I still have internet so that's a good sign. I might try again with a single LAN just to see.
I was reading this old thread and was amazed that the reverse proxy wasn't mentioned earlier. Altough i have some issue related to this post as well.
Let me explain my situation:
I am 1 step further i set up a reverse proxy that does a lot all on port 443.
It hase several web services on seperate servers behind it also SSH some protected with a client cert, and i got even RDP working in sort of a poor man's RDP gateway so yes i can RDP to multiple machines by connecting to the same address. Some fictive examples:
abc.example.com:443 -->webserver 1
xyz.example.com:443 -->webserver 2
def.vpn.example.com:443 --> webserver 3 also you need a client cert to connect.
aaa.ssh.example.com:443 --> ssh to a server
rdp.example.com:443 --> rdp to several servers, when you connect your user name should be formatted: servername\username
Now all works as designed, but when i am on my lan i want to connect to to the same addresses from intern as i do from outside. For some reason nat reflection broke after some update of pfSense and never got it working again. When i connect from inside it is reflected to the right server but it serves the certificate of my isp's modem?? Which is strange because that cert is only in the modem not in the pfSense box.
I enabled HTST in all connections in the reverse proxy so because of the cert issue i cannot connect from inside (if i turn that of it works with the wrong cert so you get nasty messages). Also using the internal DNS trick to skip the NAT reflection hack all together will not work because i am used to use all services on port 443. However all servers have their services configured on all kind of ports so i have to start remembering what to connect on which port when using the DNS solution.
Any idea how comes my modem cert is showing when using NAT refelection? O yeah one last important thing the modem is not in bridge it is just routing as well and i have put my pfsense box in DMZ of the modem to forward everything to the pf Sense box and let that do it's thing.
Like i said it worked for years and broke with pfSense version 2.4.5.
But I may know why. I'm using 2 NAT's (unfortunatelly).
I can not think of anything, what your former OpenWRT could have done here to make it work without knowing your real public IP.
If abc.domain.com resolves to the ISP routers external IP, NAT reflection must be done at the external router.
If that is not possible and you cannot use split DNS your only option will be to clone your NAT rules to your internal interface(s).
To make it work if both, server and client, are connected to the same interface of pfSense you will additionally need an outbound NAT rule for this server.
Thanks again for taking the time to communicate your thoughts.
I have no aversion whatsoever about the placement of a mailserver in full view of the Internet. The choice to place it behind a router is purely the desire to have a device that can turn a single public IP address into a multi-destination relay of traffic. Different protocols making use of that public IP address are better served by specific equipment/software on the inside. As you point out, all inbound TCP/SMTP 25 traffic has no requirement or logical reason to have the packet headers rewritten (disguised), ie inbound NAT is not even the key factor here. Maybe an elaboration would help you to understand what my mind is processing.
First location - one public IP address.
The boundary router is a AR129 Huawei product supplied by the ISP.
There are several internal machines using the connection to the internet.
There is a mailwash server using the WAN IP as a MX address in DNS.
The direction of TCP/SMTP 25 packets is done by settings within that router.
Those settings are; NAT > Port Forwarding > TCP/SMTP 25 > Mailserver 25.
Those packets are delivered to the mailserver without rewriting the packet header.
That behaviour is not an optional setting.
That port forwarding is not possible by any other means in that router.
It might be reasonable to assume that TCP/SMTP 25 inbound packets are not
having the headers rewritten by design, ie, it cannot be deemed necessary.
Second location - 1 primary public IP address + subnet/29 (8) mapped IP addresses.
The boundary router is a AR129 Huawei product (and the primary WAN IP address)
There is another boundary router being the pfSense virtual device;
It has 6 nics,
4 x WAN that service 4 of the 5 available IP addresses in the subnet/29 block,
1 x LAN address that is on the 192.168/24 subnet,
1 x DMZ address that is on the 10.179/24 subnet.
If I use the AR129 Huawei (NAT > Port Forwarding) = NO SMTP rewritten headers.
BUT that is just one public address, without rewritten inbound headers.
If I use the pfSense router (NAT > Port Forward) = all SMTP headers are rewitten.
BUT that handles 4 public IP addresses, therein is the trade-off.
I did think I was pretty smart to get a configuration that could pass 4 public IPs through to a dynamic multi-dimensional facility. The capability of the pfSense router was not rated so much for protection from the internet, as it was for the pure compactness and configurability of the routing. I had variously dabbled with a Linux box with multiple nics but that was much more cumbersome that the pfSense experience that I currently use.
Hence my goal here is to pick the brains of the obvious pool of knowledge, to see if there is some way (even undocumented) to disable the header rewrite on inbound port forwarded TCP/SMTP packets. I am hoping that the proprietary routers are an indication that it is the more prevalent mode.
@gurpal2000 does this still work? I tried some variations on this theme and none worked. I could never get the alias to stick on the WAN. But if I read the intent correctly, the NAT is taking 192.168.3/24 and translating it to 192.168.3.100/32. So maybe any address in 192.168.3/24 will translate to 192.168.3.100. I eventually had to go with a static assignment to the WAN to get to modem GUI along with a slightly different static NAT. So that needs to flop back and forth between DHCP and STATIC depending on whether you need internet of access to the GUI. OK for debugging I suppose - and what its typically needed for.
That would be my guess as well, that it aborted on that rule. Pretty sure the email notifications will alert on those types of things, as well as invalid aliases and the like (those I know appear in the GUI), so you might want to set that up in System/Advanced/Notifications in case it happens again.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.