Dual WRAP setup for co-lo firewall/router
-
I need a firewall/router system to sit in front of a few web servers in a rack at a co-location facility, and I'm looking pretty seriously at using a pair of WRAP boards in a failover setup (using the neat dual-board 1U enclosure from yawarra.com.au). I just had a few questions:
1. The incoming connection is 10Mbit full duplex. Would a WRAP be enough to handle that doing firewalling and NAT/routing for my servers?
2. I'm still confirming with the co-lo, but I may be stuck with just a single clink coming in from the WAN. Is there any option to feed the WAN link in to both boxes other than just putting a switch there?Thanks guys!
-
@lsd:
I need a firewall/router system to sit in front of a few web servers in a rack at a co-location facility, and I'm looking pretty seriously at using a pair of WRAP boards in a failover setup (using the neat dual-board 1U enclosure from yawarra.com.au). I just had a few questions:
1. The incoming connection is 10Mbit full duplex. Would a WRAP be enough to handle that doing firewalling and NAT/routing for my servers?A WRAP will push 23+ megabit. Should be fine for this.
@lsd:
2. I'm still confirming with the co-lo, but I may be stuck with just a single clink coming in from the WAN. Is there any option to feed the WAN link in to both boxes other than just putting a switch there?
Thanks guys!
You can use a switch, no problem. If you plan on using CARP just keep in mind you will need a unique IP per firewall then you will need shared IP's that both of the firewalls will share.
-
A WRAP will push 23+ megabit. Should be fine for this.
Actually this is a typo, it pushes up to 32 mbit/s depending on the packetsize (this is the best value when using netio to bench a factory default pfSense setup WAN to LAN). However you should consider that a more complex config can substract some bandwidth from that value but I think it should have no problem handling a 10 mbit/s connection.
You can use a switch in fron of your doublewraps lan but take into account that each box needs a real ip for it's own which can't be shared between the two clusternodes (see carptutorial at pfSense.com for details).
-
Thanks for the feedback guys – it looks like the dual-WRAP will be a perfect fit for us hardware-wise.
On the IP addresses for CARP, I'm a little concerned about one thing, but hopefully it's not really a problem. Our co-lo has given us just one IP for now, and we're getting a separate subnet of 16 addresses routed through that to us. Would that setup work if I just had the single IP address as the virtual WAN address shared by the two WRAPs, and gave each box an IP from the other subnet of 16? I'd imagine this would work, since as long as one of the WRAPs is up and running on the virtual IP it'll happily route through the subnet, but if someone could confirm that that'd be great. Otherwise, I'll try to put together a test setup with a couple of PCs on a LAN before I buy the WRAPs.
-
The CARP IPs have to match with the real subnet of the interface it runs on. So you need 3 IPs (1 for Firewall1, 1 for Firewall2, 1 to be shared). You can use a bigger subnet at WAN though, however you won't be able to reach few other public IPs then (depends on the subnetmask you "fake") but if you don't need access to those from your servers it should be no problem. What kind of WAN do you have? In case it is DHCP CARP also won't work, you need a static setup at WAN.
-
The WAN link is just an Ethernet cable in, with the co-lo allocating a /30 on there, so there's just two IPs – one for my router, and one for theirs, which is set as the default gateway on my router. Are you saying that I could, say, pretend that it's really a /29, giving me an extra 4 addresses, and use a couple of those extra IPs for the firewall 1 and firewall 2 IPs? I think that should be fine, since the real hosts would probably just be other people's stuff in the co-lo facility that we don't need to reach.
-
exactly
-
Cool :) Thanks again!
-
I'm back :)
I bought the dual WRAP setup, and I've set it up on my LAN to play with before deploying it to production. Configuration has gone well, and everything seems to work fine, but when doing some stress-testing the WRAP seems to fall over fairly easily. What I've done is:
1. Set up the WRAPs with the WAN interfaces connected to my office LAN, with a cross-over cable connecting the SYNC interfaces, and a separate switch behind them plugged in to the LAN interfaces.
2. Followed the CARP setup tute on the pfSense website
3. Added a third CARP IP to use for 1:1 NAT to a server on the LAN behind the WRAPs
4. Added the 1:1 NAT setup
5. Added rules to allow access from my "WAN" through to the server on the LAN.All that works well, and I'm able to connect to the web server sitting behind the WRAPs. However, when I run a HTTP stress-test using the "ab" tool, the master WRAP typically falls over after about 30-60 seconds. From what I can tell it just reboots: watching the serial console just shows the usual pfSense console, followed by the WRAP POSTing and pfSense booting, with no apparent error messages along before the reboot.
I'm at a bit of a loss to explain this – has anyone else seen similar problems? Any pointers on where to start looking would be greatly appreciated.
-
Set up a remote syslog server and see what the last messages are before the reboot happens. Also make sure you have some CPUs that can stand the load. High CPU usage consumes more power than in idle state. Also check the temperature. The CPU has a thermal sensor included that shuts the device down when it's exceeding the limit. Do both of your wraps show this behaviour or is it just one?
-
Both WRAPs seem to exhibit the same problem. I'm using 12V 1.5A PSUs, so hopefully power isn't a problem. Is there any way I can measure the temperature on the WRAP?
As far as the logs go, I got one of the WRAPs to send its logs to my Linux desktop, but I didn't see anything of use at the time of the crash: just messages from the firewall about blocking traffic that machines on my LAN must be broadcasting about. After the last one of these comes through, the next messages are from the bootup sequence:
Jun 7 17:16:46 192.168.1.97 pf: 000141 rule 75/0(match): block in on sis0: (tos 0x0, ttl 1, id 9485, offset 0, flags [DF], proto: UDP (17), length: 36) 192.168.1.95.34540 > 239.2.11.71.8649: UDP, length 8
Jun 7 17:16:46 192.168.1.97 pf: 000141 rule 75/0(match): block in on sis0: (tos 0x0, ttl 1, id 3911, offset 0, flags [DF], proto: UDP (17), length: 36) 192.168.1.95.34540 > 239.2.11.71.8649: UDP, length 8
Jun 7 17:18:43 192.168.1.97 pf: tcpdump: WARNING: pflog0: no IPv4 address assigned
Jun 7 17:18:43 192.168.1.97 pf: tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes
Jun 7 17:18:55 192.168.1.97 pf: 000000 rule 75/0(match): block in on sis0: (tos 0x0, ttl 1, id 5818, offset 0, flags [DF], proto: UDP (17), length: 36) 192.168.1.95.34540 > 239.2.11.71.8649: UDP, length 8I'm just about to throw OpenBSD on to one of the WRAPs to see if it does similar things – I'll let you know how that goes.
-
I might actually have an answer, though I can't say for sure until I get in to the office: the very high interrupt load caused by the flood of incoming connections could be tripping the watchdog timer, and looking at the init code here, it looks like the watchdog is enabled at boot. Looking at the watchdogd manpage it looks like I can kill watchdogd to disable the checking – I'll try that in the morning and let you know how it goes.