Tuesday, 20 January 2015

Not so pixie

Maybe that pix wasn't such a great buy. It has only a Failover licence, and today I found out what that means. It reboots every 24 hours. So you can't use it as the main firewall.

Oh well. It was pretty cheap, and I can still use it as a non-production firewall. I mean, I can use it to practice setting up rules, without messing up the main firewall in action.

It has a very nice web-based user interface, which has been very helpful to me in learning how to set it up. And setting it up isn't easy. It's the sort of thing where, until you have everything set up right, nothing works, and you have no idea why.

I have learned this - you have to look at the world from the point of view of a packet. So, suppose I have:

Server I that will be inside the firewall (inside means high securiry, computers I don't what the outside world to see).
Server D that will be in the DMZ interface (DMZ means lower securiry - the outside world can access them, for delivering email, for eample).

How do I allow server D to send data to server I?

Well. The inside network has servers with IP addresses like 10.x.y.z, and so the inside interface on the pix will be on I will be

I'm putting the DMZ servers all on addresses like 192.168.y.z. So the DMZ interface will be on D will be

A packet starts out on I, and I tell it to get to D.  So I tell it that it's trying to get to And off it goes on its journey. And it says to itself ...

I want to go to But I'm on, and when I look at my netmask (which is that tells me that I can get to any other server 10.x.y.z, but to go to anywhere else, I have to go to my gateway.

The gateway on I is set to, so the packet trundles over to the pix, and the pix takse it under its wing. It notices that it comes from "inside" and is trying to get to DMZ, so it's going from a high security place to a lower security place, and that's cool - it's the other way round that the pix is mostly trying to stop (although you can set up rules to bar that). So the pix moves the packet from the inside interface, to the DMZ interface, and it also tells it that instead of coming from, it has to claim that it's from (this is called NAT, network address translation) and lets it go on its merry way. Now the packet can see a server labelled, so it swims down the ethernet cable to get there.

But what if it's the other way round - suppose I send a packet from D to I. Now the packet is coming from, and trying to get to The netmask is, which tells it that it can talk to anything that starts with 192.168, but for anywhere else, it has to go to the gateway. The gateway is set as, and that's the DMZ interface on the pix. So the packet goes there.

And now the pix gives it a thorough scrutiny. Where did you come from (source IP)? Where are you going (destination IP)? What to you plan to do when you get there (port address)? There's a set of rules that the pix applies, and only if the packet passes all the tests, is it allowed to proceed. If it fails any test, then it's killed. This might seem harsh, but  it's a cruel world.

If it does pass all the tests, then it's given a new identity. It is now called "" - it's pretending to be from the pix, which in a way it is, and wearing this disguise (NAT again) it looks for its final destination

And when it gets there, server I might be running firewall software that puts it through another set of scrutinies. But eventually, it makes it to where it was sent, and does whatever it was told to do.

So - what to do about the pix525? I've just bought a pair of 515E pixes for £80; one "unrestricted" and one "failover". And I'll just move the work I've done setting up the 525, over to those. The 515E isn't quite a beefy as the 525, but it should be beefy enough for me; the 525 has a throughput of 330 mbps, and the 515E is 190. Since my line will be only 100, the 515E should be enough. And I'll use the 525 for testing.

No comments:

Post a Comment