Netgate SG-1000 microFirewall

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - swix

Pages: [1] 2
1
As a final followup, remote party updated their setup to let us use NAT translation like we usually do, and it's now working fine with:
- Local Network:  LAN Subnet
- NAT/BINAT Translation: Network   192.168.18x.0/24
- Remote Network: 10.22x.0.0/16

It would still be interesting to know if and how it would have been possible to solve the initial issue (public network as target), but at least case is closed for now.
Kind regards

2
Spent some more time on the forum & searching...    "Static routes are not possible with IPSEC" came up a few times, but I still hope there is a way.

I just miss my IPSEC remote gateways under System / Routing / Static Routes / Edit, or should I try with 127.0.0.1 as Gateway ?  I can't try it now (working remotely and no way to fix things if it brings everything offline), but if it is the way to go, I could give it a try tomorrow.


3
Oh great, an answer ! Thanks for your time cmb.

"Just need NAT in the P2" is definitely what I'd like to get, but setting "LAN subnet" under "NAT/BINNAT translation" does not have any effect (gets saved, but if I edit the entry again the field is empty : cf. screenshot).

Is this a GUI-issue, or is there another way to achieve this? 



4
No solution found yet, I will request a private range and try again.      But I'd still be happy to know if there is another way to solve this :)

5
I just updated our router to 2.3.1, and everything remained the same (which was to be expected).
I tried a few other things, but no luck yet, even when using our WAN IP as /32 network under "Local Network:"  it doesn't work anymore, only when "Local Network:  WAN Subnet " is set I can access the remote servers, and only from the router's shell.

I guess some more research is needed...  In the mean time, please do not hesitate to give any input or suggestion, thanks !

6
Bonjour, hello,

I have some "Simple" IPv4 tunnels (IKEv1) to customers here, 3 are already running.  Our LAN: 192.168.1.0/24, WAN IP address 80.254.x.y.

Already working tunnels are having a Phase 2 setup similar to:
- Local network: LAN Subnet - NAT/BINAT:  Type Network, Address 192.168.10.0/24
- Remote Network:  Type Network , Address 10.116.0.0/16

I now have to add a new tunnel, but this time and for the first time the Remote Network Address is using public IP ranges.  Current phase 2 setup:
- Local Network:  WAN Subnet - no NAT/BINAT
- Remote Network:  Type Network, Address 159.16x.y.z/30

IPSEC connection status for Phase 1 and Phase 2 are fine, everything works as planed when testing from the router itself (when connected via ssh to the pfsense system, I can ping one remote target IP as 159.16x.y.7).  But the only issue is that I cannot access the target range 159.16x.y.z/30 from our LAN (192.168.1.0/24). 

I tried changing the phase 2 settings, but with anything else the tunnel will not work.    And if I set "LAN subnet" as NAT/BINAT network, it seems to be ignored and will not be saved.
I also thought about adding a static route, but it's not possible to select a tunnel as a gateway.
So how could I route these packets to 159.16x.y.z/30 over the tunnel instead as directly over our gateway ? 

Any hint would be very welcome as I am not very experienced with ipsec topics.  Merci & kind regards, Olivier

7
General Questions / Re: Periodic since 2.2 pages load blank, certs invalid
« on: February 12, 2015, 09:29:56 am »
Final followup here for me (I hope): Unbound 1.5.2rc1 has just been released, http://www.unbound.net/pipermail/unbound-users/2015-February/003774.html

Interesting part of the release notes in our case:

Quote
This release fixes a DNSSEC validation issue when an upstream server
with different trust anchors introduces unsigned records in messages.
 Harden-glue when turned off allows potentially poisonous records in
the cache in the hopes of that enabling DNS resolution for 'impossible
to resolve' domains, it is fixed to have 'less cache poisoning',
quotes added because it is by definition not secure to turn off
harden-glue.  New features are that "inform" can be used to see which
IPs lookup a domain, and unbound-control can use named unix pipes.

According to Chris in Redmine, this should be fixed in 2.2.1.

8
Suggestion for pfSense 2.2.1 : apply this patch to unbound and/or activate the harden-options by default.  I'll check later if there is anything in redmine about this issue or will create a new one accordingly.

Voilą : https://redmine.pfsense.org/issues/4402

9
With the great support of Wouter Wijngaards from the Unbound-Dev-Team this issue can be considered as closed, at least on our side.
Activating "harden-glue: yes" and "harden-dnssec-stripped: yes" was the solution, or a patch can be applied to fix this situation without enabling these options.

Quote from: Wouter Wijngaards
Hi Martin, Olivier,

I have found the issue, it is in unbound.  You have turned off
harden-glue in config and this disabled the poison checks (that is its
purpose) and caused the poisoning.  The domain is not an attack domain
I think but a domain-reseller.

Turn on harden-glue: yes in unbound.conf

Also this patch may solve the problem (and you can continue to use
harden-glue: no).  Note that harden-glue no allows people (not this
specific attack) to poison nameserver glue records and then poison
your cache as well, also with the patch.


Index: iterator/iter_scrub.c
===================================================================
--- iterator/iter_scrub.c       (revision 3329)
+++ iterator/iter_scrub.c       (working copy)
@@ -680,7 +680,9 @@
                                 * (we dont want its glue that was approved
                                 * during the normalize action) */
                                del_addi = 1;
-                       } else if(!env->cfg->harden_glue) {
+                       } else if(!env->cfg->harden_glue && (
+                               rrset->type == LDNS_RR_TYPE_A ||
+                               rrset->type == LDNS_RR_TYPE_AAAA)) {
                                /* store in cache! Since it is relevant
                                 * (from normalize) it will be picked up
                                 * from the cache to be used later */


Why was harden-glue turned off?  And perhaps I should change
documentation or implementation of this misfeature?

Best regards,
   Wouter


More information from the Unbound-Users mailing list : https://unbound.nlnetlabs.nl/pipermail/unbound-users/2015-February/003768.html

Suggestion for pfSense 2.2.1 : apply this patch to unbound and/or activate the harden-options by default.  I'll check later if there is anything in redmine about this issue or will create a new one accordingly.

Thanks again for your fast and helpful answers on this forum & I hope it will remain stable this way !  Now I can get back to my IPSEC issues :-)
Kind regards.

PS: about the trigger :

Code: [Select]

> (...) could you see which host/device caused this issue ?

Yes, the offending query was for ns2.transitionalprotocol.net A.
The logs are missing lines (the logger seems to skip lines when
presented at a high rate).  That query was made to resolve another
query for 105.73.246.46.in-addr.arpa. PTR.
And this was requested by
Feb 10 11:48:15 pf unbound: [68609:0] debug: udp request from ip4
192.168.1.150 port 62403 (len 16)

The query for that reverse address seems innocent.

10
General Questions / Re: Periodic since 2.2 pages load blank, certs invalid
« on: February 10, 2015, 07:00:24 am »
Activating following settings (as suggested previously in this thread) seems to solve the issue for now, at least for the last 3 hours :

Code: [Select]
harden-glue: yes
harden-dnssec-stripped: yes

In the mean time I have a 500 MB resolver.log in "verbose=5" mode to analyze.   



11
General Questions / Re: Periodic since 2.2 pages load blank, certs invalid
« on: February 10, 2015, 04:25:26 am »
Does that mean you have already made all the suggested changes?

(if the question is for me) : no, as we would first would like to find out what/who is triggering this phenomena.  But we'll change the setup then (today before the evening) and report again.

12
General Questions / Re: Periodic since 2.2 pages load blank, certs invalid
« on: February 10, 2015, 04:04:57 am »
Update for our situation (only dns active, harden glue settings not (yet) updated).
The situation happened again a few minutes ago, and here it is how it looked in the resolver.log (first time "csof" is visible today)  :

Code: [Select]
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was ANSWER
Feb 10 10:03:18 pf unbound: [24807:1] info: response for 239.75.246.46.in-addr.arpa. PTR IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <75.246.46.in-addr.arpa.> 91.213.246.6#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was REFERRAL
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving ns1.transitionalprotocol.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving ns2.transitionalprotocol.net. A IN
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving f.gtld-servers.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving g.gtld-servers.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving k.gtld-servers.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving l.gtld-servers.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving ns2.transitionalprotocol.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving h.gtld-servers.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving i.gtld-servers.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving ns1.transitionalprotocol.net. A IN
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving m.gtld-servers.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving d.gtld-servers.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: response for a.ns.portlane.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <portlane.net.> 80.67.0.6#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was ANSWER
Feb 10 10:03:18 pf unbound: [24807:1] info: response for b.ns.portlane.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <portlane.net.> 80.67.0.6#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was ANSWER
Feb 10 10:03:18 pf unbound: [24807:1] info: response for 125.10.113.188.in-addr.arpa. PTR IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <10.113.188.in-addr.arpa.> 80.240.240.2#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was ANSWER
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving 113.188.in-addr.arpa. DS IN
Feb 10 10:03:18 pf unbound: [24807:1] notice: sendto failed: Operation not permitted
Feb 10 10:03:18 pf unbound: [24807:1] notice: remote address is 2001:500:13::c7d4:35 port 53
Feb 10 10:03:18 pf unbound: [24807:1] info: error sending query to auth server 2001:500:13::c7d4:35 port 53
Feb 10 10:03:18 pf unbound: [24807:1] info: response for ns1.transitionalprotocol.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <net.> 192.52.178.30#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was REFERRAL
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving ns2.csof.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving ns1.csof.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving e.gtld-servers.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving d.gtld-servers.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: response for ns2.transitionalprotocol.net. A IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <net.> 192.52.178.30#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was REFERRAL
Feb 10 10:03:18 pf unbound: [24807:0] info: response for 125.74.1.116.in-addr.arpa. PTR IN
Feb 10 10:03:18 pf unbound: [24807:0] info: reply from <1.116.in-addr.arpa.> 202.103.224.69#53
Feb 10 10:03:18 pf unbound: [24807:0] info: query response was NXDOMAIN ANSWER
Feb 10 10:03:18 pf unbound: [24807:1] info: response for ns2.transitionalprotocol.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <net.> 192.26.92.30#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was REFERRAL
Feb 10 10:03:18 pf unbound: [24807:1] info: response for ns2.transitionalprotocol.net. A IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <transitionalprotocol.net.> 212.6.183.201#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was ANSWER
Feb 10 10:03:18 pf unbound: [24807:1] info: response for ns1.transitionalprotocol.net. A IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <net.> 192.31.80.30#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was REFERRAL
Feb 10 10:03:18 pf unbound: [24807:1] info: response for ns2.csof.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <net.> 192.43.172.30#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was REFERRAL
Feb 10 10:03:18 pf unbound: [24807:1] info: response for ns2.transitionalprotocol.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <transitionalprotocol.net.> 212.6.183.201#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was nodata ANSWER
Feb 10 10:03:18 pf unbound: [24807:1] info: response for 113.188.in-addr.arpa. DS IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <188.in-addr.arpa.> 199.212.0.53#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was nodata ANSWER
Feb 10 10:03:18 pf unbound: [24807:1] info: NSEC RRset for the referral proved not a delegation point
Feb 10 10:03:18 pf unbound: [24807:1] info: NSEC RRset for the referral proved no DS.
Feb 10 10:03:18 pf unbound: [24807:1] info: Verified that unsigned response is INSECURE
Feb 10 10:03:18 pf unbound: [24807:1] info: response for ns1.transitionalprotocol.net. A IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <transitionalprotocol.net.> 54.77.72.254#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was ANSWER
Feb 10 10:03:18 pf unbound: [24807:1] info: response for ns1.csof.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <net.> 192.26.92.30#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was REFERRAL
Feb 10 10:03:18 pf unbound: [24807:1] info: response for 239.75.246.46.in-addr.arpa. PTR IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <239.75.246.46.in-addr.arpa.> 195.22.26.248#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was ANSWER
Feb 10 10:03:18 pf unbound: [24807:1] info: resolving 246.46.in-addr.arpa. DS IN
Feb 10 10:03:18 pf unbound: [24807:1] info: NSEC RRset for the referral proved not a delegation point
Feb 10 10:03:18 pf unbound: [24807:1] info: NSEC RRset for the referral proved no DS.
Feb 10 10:03:18 pf unbound: [24807:1] info: Verified that unsigned response is INSECURE
Feb 10 10:03:18 pf unbound: [24807:1] info: response for ns2.csof.net. AAAA IN
Feb 10 10:03:18 pf unbound: [24807:1] info: reply from <csof.net.> 208.109.255.32#53
Feb 10 10:03:18 pf unbound: [24807:1] info: query response was nodata ANSWER
Feb 10 10:03:18 pf unbound: [24807:0] info: response for 166.31.215.188.in-addr.arpa. PTR IN
Feb 10 10:03:18 pf unbound: [24807:0] info: reply from <31.215.188.in-addr.arpa.> 89.39.166.2#53
Feb 10 10:03:18 pf unbound: [24807:0] info: query response was THROWAWAY
Feb 10 10:03:19 pf unbound: [24807:1] info: response for ns1.csof.net. AAAA IN
Feb 10 10:03:19 pf unbound: [24807:1] info: reply from <csof.net.> 208.109.255.32#53
Feb 10 10:03:19 pf unbound: [24807:1] info: query response was nodata ANSWER
Feb 10 10:03:19 pf unbound: [24807:1] info: resolving 205.112.194.173.in-addr.arpa. PTR IN
Feb 10 10:03:19 pf unbound: [24807:1] info: resolving ns2.google.com. AAAA IN
Feb 10 10:03:19 pf unbound: [24807:1] info: resolving ns4.google.com. AAAA IN
Feb 10 10:03:19 pf unbound: [24807:1] info: resolving ns1.google.com. AAAA IN
Feb 10 10:03:19 pf unbound: [24807:1] info: response for ns1.transitionalprotocol.net. AAAA IN
Feb 10 10:03:19 pf unbound: [24807:1] info: reply from <transitionalprotocol.net.> 212.6.183.201#53
Feb 10 10:03:19 pf unbound: [24807:1] info: query response was nodata ANSWER
Feb 10 10:03:19 pf unbound: [24807:1] info: response for 205.112.194.173.in-addr.arpa. PTR IN
Feb 10 10:03:19 pf unbound: [24807:1] info: reply from <194.173.in-addr.arpa.> 216.239.36.10#53
Feb 10 10:03:19 pf unbound: [24807:1] info: query response was ANSWER
Feb 10 10:03:20 pf unbound: [24807:1] info: resolving www.insign.ch. A IN
Feb 10 10:03:20 pf unbound: [24807:1] info: resolving dns2.insign.ch. AAAA IN
Feb 10 10:03:20 pf unbound: [24807:1] info: resolving dns1.insign.ch. AAAA IN
Feb 10 10:03:20 pf unbound: [24807:1] info: response for www.insign.ch. A IN
Feb 10 10:03:20 pf unbound: [24807:1] info: reply from <insign.ch.> 46.175.9.120#53
Feb 10 10:03:20 pf unbound: [24807:1] info: query response was ANSWER
Feb 10 10:03:20 pf unbound: [24807:1] info: NSEC3s for the referral proved no DS.
Feb 10 10:03:20 pf unbound: [24807:1] info: Verified that unsigned response is INSECURE
Feb 10 10:03:20 pf unbound: [24807:1] info: resolving 64.94.172.95.in-addr.arpa. PTR IN
Feb 10 10:03:20 pf unbound: [24807:1] info: resolving ns-b.pnap.net. AAAA IN
Feb 10 10:03:20 pf unbound: [24807:1] info: resolving ns-c.pnap.net. AAAA IN
Feb 10 10:03:20 pf unbound: [24807:1] info: resolving ns-a.pnap.net. AAAA IN
Feb 10 10:03:20 pf unbound: [24807:1] info: resolving 185.112.194.173.in-addr.arpa. PTR IN
Feb 10 10:03:20 pf unbound: [24807:1] info: resolving ns3.google.com. AAAA IN
Feb 10 10:03:20 pf unbound: [24807:1] info: resolving ns4.google.com. AAAA IN
Feb 10 10:03:20 pf unbound: [24807:1] info: resolving ns1.google.com. AAAA IN
Feb 10 10:03:20 pf unbound: [24807:1] info: response for 185.112.194.173.in-addr.arpa. PTR IN
Feb 10 10:03:20 pf unbound: [24807:1] info: reply from <194.173.in-addr.arpa.> 216.239.32.10#53
Feb 10 10:03:20 pf unbound: [24807:1] info: query response was ANSWER
Feb 10 10:03:20 pf unbound: [24807:1] info: response for 64.94.172.95.in-addr.arpa. PTR IN
Feb 10 10:03:20 pf unbound: [24807:1] info: reply from <94.172.95.in-addr.arpa.> 64.95.61.4#53
Feb 10 10:03:41 pf unbound: [24807:0] info: query response was REFERRAL
Feb 10 10:03:41 pf unbound: [24807:0] info: resolving dns4.bigrock.in. AAAA IN
Feb 10 10:03:41 pf unbound: [24807:0] info: resolving dns2.bigrock.in. AAAA IN
Feb 10 10:03:41 pf unbound: [24807:0] info: resolving asia1.akam.net. AAAA IN
Feb 10 10:03:41 pf unbound: [24807:0] notice: sendto failed: Operation not permitted
Feb 10 10:03:41 pf unbound: [24807:0] notice: remote address is 2600:1401:2::43 port 53
Feb 10 10:03:41 pf unbound: [24807:0] info: error sending query to auth server 2600:1401:2::43 port 53
Feb 10 10:03:41 pf unbound: [24807:1] info: response for ns0.mirasystem.net. A IN
Feb 10 10:03:41 pf unbound: [24807:1] info: reply from <net.> 54.72.8.183#53
Feb 10 10:03:41 pf unbound: [24807:1] info: query response was ANSWER
Feb 10 10:03:42 pf unbound: [24807:0] info: response for asia1.akam.net. AAAA IN
Feb 10 10:03:42 pf unbound: [24807:0] info: reply from <akam.net.> 184.85.248.67#53
Feb 10 10:03:42 pf unbound: [24807:0] info: query response was nodata ANSWER
Feb 10 10:03:42 pf unbound: [24807:0] info: response for dns2.bigrock.in. AAAA IN
Feb 10 10:03:42 pf unbound: [24807:0] info: reply from <bigrock.in.> 2.22.230.64#53
Feb 10 10:03:42 pf unbound: [24807:0] info: query response was nodata ANSWER
Feb 10 10:03:42 pf unbound: [24807:1] info: response for ns1.epn.ru. A IN
Feb 10 10:03:42 pf unbound: [24807:1] info: reply from <EPN.RU.> 195.22.26.248#53
Feb 10 10:03:42 pf unbound: [24807:1] info: query response was ANSWER
Feb 10 10:03:42 pf unbound: [24807:1] info: response for ns0.epn.ru. AAAA IN
Feb 10 10:03:42 pf unbound: [24807:1] info: reply from <epn.ru.> 195.22.26.248#53
Feb 10 10:03:42 pf unbound: [24807:1] info: query response was nodata ANSWER
Feb 10 10:03:42 pf unbound: [24807:1] info: response for ns0.epn.ru. A IN
Feb 10 10:03:42 pf unbound: [24807:1] info: reply from <EPN.RU.> 195.22.26.248#53
Feb 10 10:03:42 pf unbound: [24807:1] info: query response was ANSWER
Feb 10 10:03:42 pf unbound: [24807:1] info: response for ns1.epn.ru. AAAA IN
Feb 10 10:03:42 pf unbound: [24807:1] info: reply from <EPN.RU.> 195.22.26.248#53
Feb 10 10:03:42 pf unbound: [24807:1] info: query response was nodata ANSWER
Feb 10 10:03:42 pf unbound: [24807:1] info: response for ns1.hn.cnc.cn. AAAA IN
Feb 10 10:03:42 pf unbound: [24807:1] info: reply from <cnc.cn.> 210.52.207.2#53
Feb 10 10:03:42 pf unbound: [24807:1] info: query response was REFERRAL
Feb 10 10:03:42 pf unbound: [24807:1] info: response for ns1.hn.cnc.cn. A IN
Feb 10 10:03:42 pf unbound: [24807:1] info: reply from <cnc.cn.> 210.52.207.2#53
Feb 10 10:03:42 pf unbound: [24807:1] info: query response was REFERRAL
Feb 10 10:03:42 pf unbound: [24807:1] info: response for ns2.hn.cnc.cn. A IN
Feb 10 10:03:42 pf unbound: [24807:1] info: reply from <cnc.cn.> 210.52.207.2#53
Feb 10 10:03:42 pf unbound: [24807:1] info: query response was REFERRAL
Feb 10 10:03:42 pf unbound: [24807:1] info: response for ns2.hn.cnc.cn. AAAA IN

At the end, all requests get resolved as "195.22.26.248".
Trigger request couldn't yet be found (the log rule on port 53 for requests not going over the router returned nothing at this moment).

So when it starts, every single request then go over one of these ns1.csof.net name server, and get answered as if csof.net was a root server, but with wrong data.  For example:

Normal case when querying the pfsense resolver (when everything is ok) :

Code: [Select]
om@ompc:~> dig -t ns @192.168.1.100 ch.

; <<>> DiG 9.9.5-rpz2+rl.14038.05-P1 <<>> -t ns @192.168.1.100 ch.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62805
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 14

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ch.                            IN      NS

;; ANSWER SECTION:
ch.                     85292   IN      NS      c.nic.ch.
ch.                     85292   IN      NS      b.nic.ch.
ch.                     85292   IN      NS      e.nic.ch.
ch.                     85292   IN      NS      d.nic.ch.
ch.                     85292   IN      NS      a.nic.ch.
ch.                     85292   IN      NS      h.nic.ch.
ch.                     85292   IN      NS      f.nic.ch.

;; ADDITIONAL SECTION:
a.nic.ch.               171692  IN      A       130.59.1.80
a.nic.ch.               171692  IN      AAAA    2001:620::4
b.nic.ch.               171692  IN      A       130.59.211.10
b.nic.ch.               171692  IN      AAAA    2001:620::5
c.nic.ch.               171692  IN      A       147.28.0.39
c.nic.ch.               171692  IN      AAAA    2001:418:1::39
d.nic.ch.               171692  IN      A       200.160.0.5
d.nic.ch.               171692  IN      AAAA    2001:12ff:0:a20::5
e.nic.ch.               171692  IN      A       194.0.17.1
e.nic.ch.               171692  IN      AAAA    2001:678:3::1
f.nic.ch.               171692  IN      A       194.146.106.10
f.nic.ch.               171692  IN      AAAA    2001:67c:1010:2::53
h.nic.ch.               171692  IN      A       194.42.48.120

;; Query time: 0 msec
;; SERVER: 192.168.1.100#53(192.168.1.100)
;; WHEN: Tue Feb 10 10:55:52 CET 2015
;; MSG SIZE  rcvd: 427


When querying this ns1.csof.net server :

Code: [Select]
om@ompc:~> dig -t ns @ns1.csof.net ch.

; <<>> DiG 9.9.5-rpz2+rl.14038.05-P1 <<>> -t ns @ns1.csof.net ch.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45232
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ch.                            IN      NS

;; ANSWER SECTION:
ch.                     172800  IN      NS      ns1.csof.net.
ch.                     172800  IN      NS      ns2.csof.net.
ch.                     172800  IN      NS      ns3.csof.net.
ch.                     172800  IN      NS      ns4.csof.net.

;; ADDITIONAL SECTION:
ns1.csof.net.           100     IN      A       54.77.72.254
ns2.csof.net.           100     IN      A       212.6.183.201
ns3.csof.net.           100     IN      A       195.22.26.199
ns4.csof.net.           100     IN      A       54.72.8.183

;; Query time: 54 msec
;; SERVER: 54.77.72.254#53(54.77.72.254)
;; WHEN: Tue Feb 10 10:45:26 CET 2015
;; MSG SIZE  rcvd: 164


I now increased the verbosity of unbound with "unbound-control -c /var/unbound/unbound.conf verbosity 4" and waiting for another hit...   If you have other suggestions in the mean time, please feel free.


13
General Questions / Re: Periodic since 2.2 pages load blank, certs invalid
« on: February 09, 2015, 12:44:44 pm »
Also, by obfuscating everything to example.com, you are eliminating the ability of everyone reading this thread from seeing what responses they get to the same queries.
Maybe someone else would get the BS responses and be in a better position to troubleshoot it than you are.

It wasn't obfuscated, it really looked like that... (also with other domains, juste replace example.com by anything)


I would put this on LAN:
pass IPv4 TCP/UDP source LAN net dest ! 192.168.1.100 port 53 log
Put that above your normal pass rule.  If everything is as you say, it should log nothing.

Ok, thanks, will setup this.


Yes, exactly. Strongly suspect most of the people here are either using some hacked ISP device that hijacks the DNS traffic or the clients do not query the pfSense DNS resolver at all.

I would be really happy to know the cause, it is really strange that Trel is having a similar problem with the very same target IP "195.22.26.248", especially from different countries/ISP's.   The only recent change to our infrastructure was upgrading to pfSense 2.2 at the beginning of January, otherwise nothing special.  But I'll setup some network monitoring tools later this week.

Best regards

14
General Questions / Re: Periodic since 2.2 pages load blank, certs invalid
« on: February 09, 2015, 11:55:10 am »
And you've actually verified that's the case on the client?

Yes, + also did tests with dig @192.168.1.100 and directly via the pfsense shell. "poisoned" ip in every case (after a few seconds after the beginning of a new occurence of the issue).


It does NOT stop the issue on domains that are not signed, no. Also, it will NOT prevent the DNS hijack if your clients are NOT using pfSense or another DNSSEC-enabled resolver, even if the zones are signed. It will prevent resolving domains to malicious crap for the rest.

Yep, I supposed that too, but sometimes there are collateral effets to such settings.


- Block/redirect all DNS queries on LAN to pfSense
- Find and reimage infected crap.

It will continue tomorrow, now it is calm again, as everybody left the office :)    But even if it is related to one malicious host on the LAN, it shouldn't be able to break the unbound resolver so easily...

Thanks again for all your feedbacks and until tomorrow!

15
General Questions / Re: Periodic since 2.2 pages load blank, certs invalid
« on: February 09, 2015, 10:56:23 am »
Ok.  So what are the DNS servers configured on the client?
     

Set via DHCP, simply the router's ip address:
Code: [Select]
   option domain-name-servers 192.168.1.100;

Pages: [1] 2