My wording was unclear indeed. My intent was that it would be interpreted to mean you can't use the same domain name on two separate networks with different entries in the DNS on each, and then expect them to know about each other and resolve the conflict on their own when you want them to interoperate.

I just assumed there was another AD box at the branch office. It seemed implied, and it seems that it was indeed the case.

I still never said anything close to 'the DNS server must be on the same subnet', I'm not sure where you're getting that from.

But it's a moot point… glad you got it working Zulan.

have you tried enlarging the images? I would make them bigger if there was not a 250mb limit on uploads

I have a few things I'm going to try when I get home from work.

One interesting bit that I did noticed and forgot to mention is that I wasn't able to ping the LAN interface (192.168.10.1) from a test machine on the same subnet.

I should also add that we do have firewall wall rules setup for IPSEC. All systems that are connected vie their DHCP client, show up as online leases and we can get to them and the LAN interface over IPSEC.

Any ideas?

System –> Packages
Now click the + button next to the package you wish to install.

Everything is working fine now. Looks like the problem was my ISP's DNS server. =/

I can ping those
@http://wiki.telecomsucks.com/Lista_de_Servidores_DNS:

*  IPlan: 200.69.193.1 (dns1.iplanisp.com)

* IPlan: 200.69.193.2 (dns1.iplanisp.com.ar)

I just want to use my domain in my own server. My server would be dedicated for live streaming and video streaming thru Flash Media Server. I want to be able to use my domain for exp: rtmp://MYDOMAIN/APPLICATION/INSTANCE and give my domain to the clients in set of the IP address, I will not host a web site in my server. So what I need is instruction in how to acomplish this, in how to host my own domain in my own server.

Thank you for the feedbacks.

I've restored both pftpx and sshd services on my system. I did so by downloading the following files from the "Diagnostics: Command" web page on a known working system (and just for good measure, I picked one with an identical firmware build date of the embedded 1.2-RELEASE):

/etc/passwd /etc/master.passwd /etc/pwd.db /etc/spwd.db

I uploaded those files on the broken system via the same page, "Diagnostics:Command". That put them all into /tmp so I executed the following four commands to move them into /etc:

cp /tmp/passwd /etc/passwd cp /tmp/master.passwd /etc/master.passwd cp /tmp/pwd.db /etc/pwd.db cp /tmp/spwd.db /etc/spwd.db

Then rebooted, and the pftpx, sshd, and port forwarding services all came up as expected.

I also satisified my curiosity about the mysterious inetd services on ports 19000+ It looks like the port forwarding is handled by netcat….

fw:/etc#  cat /var/etc/inetd.conf 19000   stream  tcp     nowait/0        nobody  /usr/bin/nc nc -w 20 192.169.1.3 25 19001   stream  tcp     nowait/0        nobody  /usr/bin/nc nc -w 20 192.169.1.3 80 19002   stream  tcp     nowait/0        nobody  /usr/bin/nc nc -w 20 192.169.1.3 110 19003   stream  tcp     nowait/0        nobody  /usr/bin/nc nc -w 20 192.169.1.3 8383 19004   stream  tcp     nowait/0        nobody  /usr/bin/nc nc -w 20 192.169.1.4 80 19005   stream  tcp     nowait/0        nobody  /usr/bin/nc nc -w 20 192.169.1.5 80 19006   stream  tcp     nowait/0        nobody  /usr/bin/nc nc -w 20 192.169.1.7 25 19007   stream  tcp     nowait/0        nobody  /usr/bin/nc nc -w 20 192.169.1.7 80 19008   stream  tcp     nowait/0        nobody  /usr/bin/nc nc -w 20 192.169.1.7 110 19009   stream  tcp     nowait/0        nobody  /usr/bin/nc nc -w 20 192.169.1.7 443 19010   stream  tcp     nowait/0        nobody  /usr/bin/nc nc -w 20 192.169.1.21 80 fw:/etc#

Also verified that from an untrusted host on the WAN, the only open ports are the two proxies I expect to see:

(The 65533 ports scanned but not shown below are in state: filtered) PORT     STATE SERVICE 21/tcp   open  ftp 1723/tcp open  pptp Nmap run completed -- 1 IP address (1 host up) scanned in 180.733 seconds

So, if there was a remote compromise it would have likely been via one of those services.

My process for finding different files was mainly to run md5 /etc/* via the web command line, and then diff'd the results against a known good system.

Maybe you can customize this to your needs
http://forum.pfsense.org/index.php/topic,9729.msg55580.html#msg55580

I haven't played with the package in a long time, but I plan on getting up to speed on pfDNS. IIRC, the failover stuff is pretty straightforward- you fill in a box for the failover IP and monitor IP. If you want to do this on the firewall, you would want to publish an NS record for your primary and secondary WANs. I think the problem with ANY failover DNS implementation is the downstream caching. IMO, this makes failover DNS records of questionable value for shorter outages. Besides laziness, that's why I  just tell users to try webmail2.company.com if they can't get in at webmail.company.com. If the outage was prolonged, I could just update the record manually anyway.

What DNS servers did you set?
Did you enable the "Allow DNS server list to be overridden by DHCP/PPP on WAN" checkbox?

Sorry, finally getting back to this project. Got the permissions fixed:
http://tomdavidson.wik.is/How_To/Home_Net

Its clear I need more help that with just DHCP, but sticking to DHCP…
If a host is statically defined rather than DHCP client, does the host name get registered in pfsense DNS server?

-tom

http://forum.pfsense.org/index.php/topic,11159.0.html

Basically it uses dnsmasq as a dns query cache (10.000 addresses), before it will ask the ISP or OpenDNS dnsservers.

Moving the dsnmasq "bootup" before the timesync works, only problem is updating new images/tgz updates.
Before mayor updates remove the "/etc/rc" and "/etc/rc.bootup" modifications.

Well, unsurprisingly, the problem has not gone away.  ??? Occasional clients are still getting the rogue gateway.

There has never (intentionally) been a DHCP server running on the 3G client. This client is a Windows XP Pro machine, and looking in the control panel the only DHCP service I could see was a DHCP Client service which appears to run on XP by default.

Also, as I mentioned earlier I could see the DHCP handshake - request, inform, ack, etc in the pfSense DHCP logs, showing the IP the client received, but then an ipconfig /all on the windows client (not the 3G one - just another client on the network) showed the DHCP negotiated IP from pfSense, but the gateway IP is the one of the 3G client.