Aliases dont work on OPTx interfaces
-
2.2-RELEASE (amd64)
built on Thu Jan 22 14:03:54 CST 2015
FreeBSD 10.1-RELEASE-p4I've noticed the aliases just dont work on some (not all) OPTx interfaces, to get around the problem I'm having to add the ip addresses to the OPTx fw rules to get something out (everything is default drop on OPTx interfaces).
Any suggestions or things to look at to find out why Aliases dont work on some interfaces, reboots dont change anything either?
TIA
-
Give an example of an Alias and a rule that uses it and does not work.
That stuff all works fine for me - so there is likely a problem with some rule setting. -
Layer 8 problem.
-
Yup clearly layer 8 here.. Nothing to see, move on ;)
-
Don't dismiss this too quickly without hearing any of the details. He clearly said it seems to be working for some OPT interfaces.
-
From information given I stand by my layer 8 diagnosis ;)
-
It could well be layer 8 & I'll be the first to admit it if it is ;D but I'll try to get some examples posted once I've understood more whats going on.
All I can say at the moment is (starting with a default drop on everything), where I have created an allow rule for one or more FQDN's in an alias record, the traffic cant get out but if I change the alias in the fw rule to an IP address and duplicate the rule immediately below its current position for the remaining additional IP addresses that would be from one of many FQDN's in the Alias record, the traffic gets out.
Now this could be because I'm using the default Resolver with TTL set to the maximum allowed and not a typipcal TTL of a day or 8,640,000 seconds, the IP's I've added to a fw rule may not be matching Resolver or the alias list if it doesnt update in realtime, but when I've checked Resolvers logs I can see it contacting and looking up the IP addresses from the relevent tld servers at the same time traffic tries to get out suggesting the alias fqdn is having its ip address looked up and thus should be getting the latest IP address from resolver.
Something else which also detracts from the typical setup is I'm using multiple usb nics with direct cables to devices to work around not having a vlan switch at my disposal. In theory the multiple usb nics should still give me the desired network isolation the vlans would normally afford me. So far from what I've seen of USB nics on pfsense is FreeBSD doesnt remember the USB device id order and so resets this possibly becuase its forced to reload the USB devices in one go somewhere deep within FreeBSD. I see similar in Linux where adding multiple usb mem sticks resets the mounting order if the more common approach of mapping devices to mountings are used eg ls -l /dev/sd* which returns /dev/sda1, /dev/sdb1 and so on, the sda, sdb, sdc order changes. In Linux a better approach to matching usb devices to mount points is to use something like
ls -l /dev/disk/by-uuid/ and then use UUID=[hexnumber] /mnt/hd vfat defaults,nodiratime,noatime 0 2. I suspect (havent looked yet) the USB nic handling in pfsense is not using UUID to map usb nics to pfsense interfaces which would then throw up its own problems, if freebsd/pfsense can access a UUID from a usb nic, if, usb nics supports UUID., I dont know I need to check this out. My background is windows, not linux so still learning alot about linux as I go along as well, but have already noticed one pattern in Google, the links suggested by google to some forums containing answers to problems are often actually wrong answers but only show they are wrong when additional steps are carried out over and above the steps suggested in the forum presented by Goolge. This is not the first time I have seen Google giving out the wrong answer but is quite possibly in googles eyes, the most popular answer, hence why wrong answers are appearing in Google. Now whilst we all have our own google filter bubbles, what google deems is a popular answer for me, may be different to someone else googling the exact same term elsewhere in the world, but if lots of people are getting links suggested to them by google for fixing some problems with computers, then some of them will be wrong and peoples internet security is going to be very poor with some gaping holes in their security.As I'm also using multiple nics instead of vlan, thats how I also know some aliases work on some interfaces and some dont as some computers have virtually identical rules & orders. Doing something out of the ordinary like this can sometimes show up previously unseen problems, its one of the flaws of some automated testing software, and undiscovered bugs could be the next zero day exploit and I also cant rule out our ISP might have been hacked as well. I've seen a story in a major national paper asking the same question and with them now implementing 2 factor authetication they are certainly now in the process of upgrading their systems, but we saw problems with the ISP back in Nov & Dec and the questions about if the ISP was hacked only appeared toward then end of Jan.
So still testing and looking up info at the moment and making sure iptables in the devices is also working properly and has its own machine locked down as much as possible.
Does anyone know what constraints Aliases might have regarding max numbers of aliases records that can exist or is this down to system resources like how much disk space exists?
-
tl;dr :P
- Why are you messing with TTL and with what settings exactly?
- Are you mixing FQDNs and IPs in an alias?
-
Yep, there's a current bug involving nested and mixed aliases you might have hit. Does this apply to your configuration: https://redmine.pfsense.org/issues/4296
Steve
