i understand your point and i don't think that is a public ip.  i switched from no-ip to dyndns and it's working now.

"Interesting. My ISP's DNS returns 120.0.9.200 and 120.0.29.201 for www.abc.net.au and that is not the same as any of the results from the OpenDNS servers."

Last time I checked AU was quite LARGE ;)  And I don't see any opendns in AU anywhere.  Closest prob Singapore…  So yeah your going to point somewhere else -- I am quite sure that akamai has servers in AU that your ISP prob resolves because its in the AU.  But when opendns looks to see where it should go, akamai has their dns setup using geoip to say oh your from Singapore -- you should use these servers.

This is one of the flaws in opendns - they don't have full coverage of the planet, so not ever user is going to be using a dns server in their region.  So anything that uses geoip to determine where it should send you is going to be in error.

Websense uses the same sort of thing for which proxy you should use in their cloud service, based upon source of where your dns query came from you get sent to different clusters.  For example if I ask my ISP dns I get

;; QUESTION SECTION:
;webdefence.global.blackspider.com. IN  TXT

;; ANSWER SECTION:
webdefence.global.blackspider.com. 60 IN TXT    "Hello 68.87.72.137 (2C),  - you go to cluster-n"

--
;; ANSWER SECTION:
137.72.87.68.in-addr.arpa. 1294 IN      PTR     chic-dnssec02.area4.il.chicago.comcast.net.

See that query came from my ISP dns 68.87.72.137, if I do a query from my own IP using my own BIND server I get same thing - because I am also in the Chicago area

;; ANSWER SECTION:
webdefence.global.blackspider.com. 60 IN TXT    "Hello 24.13.xx.xx (2C),  - you go to cluster-n"

If I use my VPS out in CA I get told to use a different cluster

;; ANSWER SECTION:
webdefence.global.blackspider.com. 120 IN TXT   "Hello 173.245.xx.xx (2W),  - you go to cluster-g"

You might want to look for different service other than opendns that has dns located in AU, or your going to have all kinds of issues with any sort of cloud service that uses geoip to send you to the closest server for where your request came from.

It would be a never ending battle trying to over ride all the domains that use geoip based results.

edit:  question for you, what is the response time when using opendns.  I am here in chicago, which they are suppose to have one in the area.  And I get 30ms response

ubuntu:~$ ping 208.67.222.220
PING 208.67.222.220 (208.67.222.220) 56(84) bytes of data.
64 bytes from 208.67.222.220: icmp_req=1 ttl=52 time=36.6 ms
64 bytes from 208.67.222.220: icmp_req=2 ttl=52 time=32.2 ms
64 bytes from 208.67.222.220: icmp_req=3 ttl=52 time=33.3 ms

I am curious what your response time is - if in fact the closest one to you is in Singapore.

Look even here in chicago its like 40ms to get a response from them

; <<>> DiG 9.8.1-P1 <<>> @208.67.222.222 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60922
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.        189    IN      A      74.125.225.176
www.google.com.        189    IN      A      74.125.225.179
www.google.com.        189    IN      A      74.125.225.180
www.google.com.        189    IN      A      74.125.225.178
www.google.com.        189    IN      A      74.125.225.177

;; Query time: 39 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Fri Jan  4 10:03:47 2013
;; MSG SIZE  rcvd: 112

If I query my isp (comcast) its much lower

; <<>> DiG 9.8.1-P1 <<>> @75.75.75.75 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49553
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.        39      IN      A      74.125.225.211
www.google.com.        39      IN      A      74.125.225.210
www.google.com.        39      IN      A      74.125.225.212
www.google.com.        39      IN      A      74.125.225.208
www.google.com.        39      IN      A      74.125.225.209

;; Query time: 18 msec
;; SERVER: 75.75.75.75#53(75.75.75.75)
;; WHEN: Fri Jan  4 10:05:32 2013
;; MSG SIZE  rcvd: 112

Like to see the same sort of tests for you..  I did a quick search and did not come up with any alternatives for opendns that have locations in the AU/NZ region of the world.  If what your wanting to do is filter via dns for your specific machines in your network.  Maybe you want to setup your own filtering so that its local.

Tx Jimp!

I think I'll manage to do what I wanted now.

/Peter

@jimp:

You can use the cron package to manage cron entries.

And for that kind of task you can use the "fetch" command or perhaps links (we include links, not lynx, they are similar but not identical)

Hi,

I'm thinking the exact sequence of commands is probably a factor.  Sorry I don't have more detailed logs or config files to diff (I've restored by normal config to get my ADSL working again).

Since there were changes in this area for 2.1, perhaps we should ignore this bug for now, unless other users can provide better information.

Best wishes for the new year.

Martin

Here's how I deal with the incomplete implementation of DHCP Client.

Screen shots and old 2.0 patch here:
DHCP Client Additional Custom Options Patch
http://forum.pfsense.org/index.php/topic,40194.0.html

2.1 patch here:
Advanced DHCP Client Options & Config File Override
  Protocol Timing
  Send Options
  Request Options
  Require Options
  Option Modifiers

https://github.com/bsdperimeter/pfsense/pull/275

Optional config override file example from 2.0.1.

# Actiontec MI424-WR Router Impersonation # ISP: Frontier FiOS # Router Make: Actiontec # Router Model: MI424WR-GEN2 # Router HW: Rev. F # Router FW: 20.12.2.4 # pfSense 2.0.1 (FreeBSD 8.1) #interface "de1" { interface "{interface}" { # DHCP Protocol Timing Values timeout 60; retry 1; select-timeout 0; initial-interval 1; #bootp-broadcast-always; # Bootp flags: 0x8000 (Broadcast) # DHCP Protocol Options send dhcp-class-identifier "Wireless Broadband Router"; # Option 60 ## Hard Coded Class Identifier send dhcp-client-identifier ""; # Option 61 ## Blank to Prevent Send #send host-name "Wireless_Broadband_Router"; # Option 12 ## Hard Coded Host Name send host-name "{hostname}"; # Option 12 ## Obtained From Web Configurator (WAN Hostname Setting) send domain-name "home"; # Option 15 ## Hard Coded Domain Name # V-I Vendor-specific Information # Option 125 ## Hard Coded MAC #send option-125 "\x00\x00\x0d\xe9\x1f\x01\x06000FB3\x02\x0c00180160EB84\x03\x07MI424WR"; #send option-125 00:00:0d:e9:1f:01:06:30:30:30:46:42:33:02:0c:30:30:31:38:30:31:36:30:45:42:38:34:03:07:4d:49:34:32:34:57:52; # V-I Vendor-specific Information # Option 125 ## Obtained From Web Configurator (WAN MAC Address Spoof Setting) #send option-125 "\x00\x00\x0d\xe9\x1f\x01\x06000FB3\x02\x0c{mac_addr_asciiU}\x03\x07MI424WR"; #send option-125 00:00:0d:e9:1f:01:06:30:30:30:46:42:33:02:0c:{mac_addr_hexU:}:03:07:4d:49:34:32:34:57:52; # Parameter Request List # Option 55 ## Hard Coded Parameter Request List #request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, time-servers, log-servers, default-ip-ttl, interface-mtu, vendor-encapsulated-options, dhcp-requested-address, dhcp-lease-time, dhcp-server-identifier, dhcp-parameter-request-list, dhcp-class-identifier, dhcp-client-identifier, www-server, option-125; request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, time-servers, log-servers, default-ip-ttl, interface-mtu, vendor-encapsulated-options, dhcp-requested-address, dhcp-lease-time, dhcp-server-identifier, dhcp-parameter-request-list, dhcp-class-identifier, dhcp-client-identifier, www-server; require subnet-mask, domain-name-servers, routers; # These are required by the client script "/sbin/dhclient-script"; }

Not directly related to the OP in this thread but it's quite similar:

If your upstream DNS does not return NXDOMAIN on failure, but rather returns an IP for its oh-so-helpful (not) search page instead, you can see similar failures to resolve DNS in the expected order.

If you resolve host "www.google.com" (no trailing .) and it tacks on the domain, "www.google.com.example.com" and your upstream DNS returns a response record for that, it will use that IP. OpenDNS does this, so their landing page IP 67.215.65.132 may turn up in your DNS responses.

DNS needs to see the NXDOMAIN to continue the search, so if you can switch off that option in your upstream DNS that's best, failing that, change to an upstream DNS server that does return proper NXDOMAIN records.

Another similar failure can happen if you use wildcard DNS for your domain.

It's working! I installed a new nic in the PCI slot.  I was using the onboard MB nic before for opt1.  apparently it was crap.  Thank you for all your assistance on helping me figure out it was a hardware issue.

If you worked with the other dyndns code, is it somehow possible to trigger the detection of the external WAN address and write that to a file? That whould help, as it could be written to the nsupdate file.

@bradenmcg:

In my area, Time Warner will issue up to 3 IPs (free) on my tier of service.

How are these IPs allocated? On request by DHCP? Do the requests need to come from different MAC addresses?

Perhaps there is a single IP address and you can use an additional two on the same subnet?

@bradenmcg:

I guess I could work-around by plugging the cable modem into my (managed) switch and using VLANs and OPT interfaces to get the additional IPs without requiring more physical interfaces on the pfSense box… But I'd have to treat them like a multi-WAN setup, which it really isn't - just multiple IPs that I'd like to be able to use as alternate sources / rule options for "WAN."

How do you envisage that would work?

Without more details of how this "issue up to 3 IPs" happens it is difficult to answer your questions.

Will these IPs be very dynamic? If so, what would be the use of using them as "alternate sources for 'WAN'"?

@Nonsense:

Ah, I tried the setup quickly, early this morning, when I was in a rush.  I retried it again and discovered that I had neglected to configure the "destination" changes in the rule this morning.  It appears to be working now–I'll find out if it still works the next time I reboot pfSense.  Thanks ptt and johnpoz.

:)

Bad network admin.  Fixed/hardcoded IPs on clients are bad juju.  pfSense can do DHCP reservations - use them.  DHCP makes your life much easier.  Why do you want your life to be difficult?  ;D

Oh, I overlooked the fact you said it's only attempts that's triggering Snort, I thought you actually had responses going out. Generally the requests will come in at a rate adequate to peg your upstream, which you'd notice, and your states show you aren't actually responding. What you're seeing is just typical Internet noise that you can't do anything about. Usually such attempts are targeted at IPs that are known to be running an open resolver, so if you have a dynamic IP that's recently been assigned to you, it's likely someone else was running an open resolver on that address previously. Sometimes they're just blindly fired though. You just have to ignore things like that, nothing your ISP is going to be able to do or even cares about, and nothing you can do about it. You're blocking it.

This is a good example of why I usually don't run Snort on WAN or outside the firewall. Too much noise that you're blocking and hence don't need to care about. Snort generates enough noise without adding a slew of things you're blocking to the list.

OK I will try to make tests. Thanks. I´ve just notice that some firewall rules stop to work after returning to original factory and recover the backup. For example my rule to send all packages on the 443 port to my wan link (to not use loadbalance because access to banks).

Thanks and regards

Perhaps you have multiple DHCP servers on your network.

Perhaps you have another system with IP address 192.168.1.188

I quit running squid after I reset to defaults, but by that time the disk was full. I ended up reinstalling because I was already at near zero configuration.

I am 100% sure that squid was culprit, or my configuration of squid to be exact. I'm guessing I added a digit when I was setting up the amount of disk space it could use for caching.

Does your dhcp server also do NAT for your network, or route your other devices that are on public IPs?

pfsense is designed to be your networks gateway/firewall to the internet.  It can be used as just an internal router/bridge/firewall - but by default its going to expect your internet to be on its WAN, and then NAT all your devices to your public IP behind it.

I am guessing your dhcp and if it does dns that is maybe a AD DC?  If so it should be behind your gateway/firewall - and you can just have it forward its external dns to pfsense, or outside for public dns.  And all your internal clients would still use it for your internal AD dns, etc.

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

I fixed this up on 2.1 last week

https://github.com/bsdperimeter/pfsense/compare/752c6ca8117e05e6bb74115d2199dab7ff99168d…0a35ca7ccf198cfa6654ccc17741005a58cd6aee