DNS Perhaps?
-
Hi there,
I am new to pfSense. We switched over from our router to pfSense 2.0.1. We host dedicated servers that are accessable via RDP using a domain name + port. So if you were a client we would give you yourdomain.com:4201. We setup a record to point that domain to one of our IP's and use NAT to forward to the proper local IP.
This has worked fine before pfSense and still works fine if your on the WAN side. If we try to connect locally (LAN) side it doesn't work unless we use the local IP address. Before, if you wanted us to make a change on your server we would log on the same way you do with RDP yourdomain.com:4201 now we have to use the local IP to connect.
Not really a big deal, more of a nusence.
We want to start moving over some websites and that will be problematic if we dont figure out how to correct this issue as the webservers will use symlinks.
To me it seems like a DNS issue, but it's probably an improper pfSense setup. Does the WAN/LAN need to be bridged? Was I wrong in thinking that pfSense would do well to function as a router and firewall?
The reason for switching from a network appliance to pfSense was to be able to bill for bandwidth usage of our hosting clients (Virtual & Dedicated).
The plan in the near future is to bring over the rest of our external IP's but I am reluctant to do so as I feel setting up virtual IP's will be problematic.
Anyway thanks in advance for any insight.
-
you need to enable nat reflection if you want to access your outside ip or fqdn that resolves to your public IP and have pfsense forward it back in.
-
you need to enable nat reflection if you want to access your outside ip or fqdn that resolves to your public IP and have pfsense forward it back in.
If you are using the pfSense DNS forwarder for clients downstream of pfSense you can also add a Host Override to point to the "local" IP address but that might not work if the servers are "fussy" about source IP address.
-
you need to enable nat reflection if you want to access your outside ip or fqdn that resolves to your public IP and have pfsense forward it back in.
If you are using the pfSense DNS forwarder for clients downstream of pfSense you can also add a Host Override to point to the "local" IP address but that might not work if the servers are "fussy" about source IP address.
Please also note that there is (probably) a difference between the DNS servers and the resolvers (CNS), possibly the authorative name servers (ie DNS-Servers) does not act as resolvers at all or only for certain networks. Maybe you need to create an internal resolver if you can not forward queries to a resolver on the outside.
Does the rules on the LAN interface permit login to your RDP ports?
Probably you need to add an internal resolver with a separate set of zones; on the outside of your WAN your servers might be reachable on public IP-addresses (ie 1.2.3.4) but if you use RFC1918 addresses and NAT internally (ie internal IP addresses looking something like this: 10.x.y.z, 192.168.x.y, or 172.16.x.y etc) on your OPT- or LAN-interfaces you might need to make sure that server.somedomain.tld does not point to 1.2.3.4 but instead to 192.168.3.4.
I you previously used a Cisco Firewall or any other firewall that "automagically" translates replies in DNS you might not have had this "problem" until now. PF Sense does not automatically transform data inside a DNS reply packet (which is a good thing IMO).
If you don't want to run multiple bind instances or separate resolvers (for example one with the "public" data and one resolver with the internal data, both servers located on the OPT interface but only the public server is allowed traffic from the outside (WAN)) you could use the hosts file on your client(s) accessing the servers from the inside (Lan or Opt). The hosts-file is usually located in /etc/hosts and uses this syntax: ip-address hostname, example:
1.2.3.4 some-servername.domain.tld alias
127.0.0.1 localhost.domain.tld localhost
etc.Cheers,
E -
If you haven't seen it: this might help you:
http://doc.pfsense.org/index.php/Why_can't_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F
