Archive for the ‘pfsense’ Category
pfsense, dnsmasq & source interfaces
I’m having issues with dnsmasq on my pfsense router being unable to contact an overridden nameserver because they’re not being sourced from an interface that has an ipsec policy. For example, I have the following config:
Main Office Router A:
LAN address: 192.168.1.1/24
WAN address: 24.1.2.3
Remote Office Router B:
LAN address: 192.168.2.1/24
WAN address: 64.1.2.3
The two sites are connected by an ipsec tunnel. My internal nameserver serving the domain “company.local” is at 192.168.1.10.
Since the remote office is on the other side of the world, I want to use the ISP nameservers for internet resolution, but send all resolutions for company.local through the tunnel to 192.168.1.10.
When dnsmasq sends the packet to 192.168.1.10, however, it uses the default route and sends the packet out of the WAN interface and not through the tunnel. My first thought was to instruct dnsmasq to use the LAN interface as its source address, such as:
/usr/local/sbin/dnsmasq -l /var/dhcpd/var/db/dhcpd.leases -s remote.company.local –server=/company.local/192.168.1.10@192.168.2.1
Indeed that works, but web UI doesn’t allow for that sort of syntax, afaik.
Failing that, I tried adding a bogus route on Router B in hopes that the packet will be redirected through the ipsec tunnel before actually being transmitted on the LAN interface. I added a static route for 192.168.1.10/32 to the gateway 192.168.1.1. This appears to work, so my problem is resolved for now. It doesn’t seem to be a particularly elegant solution, however.
Server load balancing in pfSense 1.3
I was poking around at the 1.3-ALPHA-ALPHA pfSense, and it looks like slbd is going to be replaced with OpenBSD’s relayd! I can’t tell you how happy I am about this development. Not only will relayd increase pfSense’s feature set by some order of magnitude, I have hope that it will make pfSense a viable load balancer.
Though pfSense has load balancing features right now, its limitations make it mostly unusable for my applications. The way that slbd operates breaks session stickiness. I’m not sure why, but I suspect that slbd is updating its pf anchor unconditionally per polling period which causes pf to reset its session state. In addition to breaking stickiness, this causes load to be balanced unfairly.
I’ll have to do some testing to see if relayd has this say behavior. If nothing else, though, I’m excited about a whole new host of features, some of which I haven’t seen since I last touched a NetScaler:
- Layer 7 (in addition to Layer 3) load balancing
- Layer 7 health monitoring (http request/response checking)
- In-Flight HTTP request/response modifications (such as appending Remote-Host header)
- Additional balancing algorithms, including one that can be sticky on HTTP headers/cookies
All-in-All pretty fantastic. I don’t imagine we’ll see 1.3 until Q2 of 2009, though, so it may be worth back-porting it as a package for 1.2.1.
pfSense’s poorly documented ftp proxy
It turns out that when you (a) disable the “disable ftp-proxy” on the WAN interface and (b) create a NAT rule that uses port 21, the ftp proxy will be automatically (and silently) started in the background. If you then modify that NAT rule, the ftp proxy application will not be updated (presumably until a reboot), but if you delete and create the rule again the ftp proxy will be started anew with the updated information.
Forcing CARP failover using pfSense
Anything that has a master/slave cluster should have some sort of mechanism for failing from the master to the slave, right? We’ll see…
pfSense provides HA via OpenBSD’s (very excellent) CARP. Of course I could just increment the advskew on all of the interfaces to fail them over individually, but that doesn’t really work for me. That involves spending some amount of time in a partially failed-over state. Having quite a bit of experience with OpenBSD, I expected there to be a more elegant solution and I certainly wasn’t disappointed. It looks like OpenBSD provides interface groups and a setting called “carpdemote”. Incrementing carpdemote on the master’s “carp” group would cause all carp interfaces to fail over to the next-in-line. nice.
I guess I was just expecting FreeBSD to have the same functionality. FreeBSD 7.0 does have interface groups, but I can’t find carpdemote in the documentation. Still, maybe pfSense 1.2.1 will be worth the upgrade afterall.
All-in-all, forcing the failover one at a time wasn’t so bad. Upping the advskew on all interfaces to 200 from a shell loop like the following got the job done, but that race condition just doesn’t sit well.
for i in 0 1 2 3; do
ifconfig carp$i advskew 200
done
Then I did my work and rebooted the master. When the master came up, all of the interfaces were reset to an advskew of 0, which is less-than-ideal-but-still-expected. Strangely, this didn’t cause the interfaces to fail back to the master. For about 5 minutes the master interfaces remained BACKUP even though the master interfaces had an advskew of 0 and the backup had an advskew of 100.
After about 5 minutes all of the interfaces failed back to the master. I expect this is just a relic of how the advskew parameter actually works by tuning carp announcement intervals.
tech stuff. 