Didn’t sleep at all last night, didn’t help when Jamie decided not to go to bed until around 5AM and the dog was busy throwing up. Then the phone went, it was mother, ignored. Got up and spent the bulk of the very horrible day working, well testing the mobile game, I think that’s the last day on that now, back on Android tomorrow I think.

In between testing on iPod I was installing the new pfSense box. Pain in the ass part one. So the pfSense box has no drives, all it has is a compact flash card. So to install pfSense on to it is quite a challenge. So I installed Ubuntu desktop edition to a USB stick, using Ubuntu desktop edition, which is full of bugs as far as writing out an image is concerned. You select the image name in the file selector and then it ignores you and uses whatever it can find. Anyway after getting the bootable image the next thing to do is copy an uncompressed CF image of pfSense to the stick as well. Also copy over GAG boot loader as it doesn’t suffer the PXE boot problem to do with wake on LAN (look back a few months in the blog). So when you have your image, now plug stick into pfSense box and boot it, allow about ten minutes for it to boot. Struggle to find a bash shell, open it and then block copy over the pfSense image over to the CF card using linux DD command. Once that’s done, install GAG and run the install on the CF card, it will moan about GRUB needing installing but it’s already there. Remove stick and reboot. Hopefully you will get the GAG startup screen, add the pfSense partician to the loader and set the timeout to this partician. Once that’s done let the bloody thing boot. Hopefully all will be okay and you can assign the first couple of NIC’s to WAN and LAN. Once that’s done, take your old pfSense config XML file and do a search and replace for all the interfaces and replace all the bge0/re0 stuff with the correct interface assignments. Then restore that file over to the new pfSense box and reboot. Hopefully all will come up and be working, well it was for me….except one thing, there’s always the one bloody thing….

I couldn’t connect to my server on the DMZ from the LAN side, no matter what I did, it just wasn’t happening. It’s all to do with NAT reflection, basically if you try and connect to the web server from inside the LAN it has to send out a request from the LAN IP, via the gateway, out of the WAN interface, then back in the WAN interface, through NAT and then to the server, it then has to make the whole trip back. The only way I could get it to work was to use port forwarding for each of the ports on both server IP’s and then only worked if I used the proxy to do reflection, which basically runs a deamon to ram the packet request back down the same port it came from. This worked, but I wasn’t happy about it.

So went to the gym. Came back after thinking about it, a lot. So I added a firewall rule to log packets from the netbook, just to see where they were going. With the port forwarding and proxy reflection nothing showed up in the firewall log. So I disabled the port forward and I could see the request then going out to the WAN IP address and promptly getting lost in the either. So I enabled normal reflection on the 1:1 NAT, then on the log I could see the WAN IP being translated to the internal LAN IP….and getting lost somewhere in the internal LAN. So had to think about it…there was some guff in the advanced settings about reflection only working if the rules could determine the source interface on rule loading. So then, when the request is generated LAN side it then translates it to the LAN IP from the WAN IP via the NAT 1:1 translation, it then sends it via the gateway, which is the load balancing gateway, so it could potentially send it via either WAN1 or WAN2, then it really is going to have a bit of an issue trying to work out well the hell to reflect it to. So I added a rule to the LAN which was to send all packets destined for the internal LAN IP’s of the server via the default gateway. Bingo. That worked a treat, and thinking about it, it’s the correct solution. So now when a request is set from an internal LAN IP to a WAN IP on the server, it takes the source IP, looks at the destination as that’s a 1:! NAT mapping it translates it from the WAN IP to the internal LAN IP, it then sends that via the default gateway, which then goes through the default WAN (I’m not sure it actually ever gets that far as it really doesn’t need to), goes to sever, server then replies back via the default gateway and gets translated back to the correct IP. Job done. Hours of fun, for which I didn’t have hours for.

Mother sent an email, apparently her curtain rail has fallen down. Sorry, but during the week I have 24 hours in a day, excluding the ones I’m asleep for I still have 37 hours of stuff to cram in. Your curtain poll is not high on my to do list. I still have a load of home checks to do as well. The dog didn’t even get a walk today, as the only breaks I had it was absolutely pissing down. We did have a play with her ball though when I came back from the gym. But she’s off to doggy day care tomorrow, so that’ll make up for it. She’s actually been very good considering, I don’t think she was overly keen on venturing out anyway.

My drain cleaning attachment has turned up for my pressure washer.

Right, well hopefully that’s the last about pfSense now. Incidentally it uses around 17 watts considering the old box was around 85, so that’s a hell of a power saving. Also it’s performance appears to be very good, I was getting some pretty good speed tests results. Right, I’m now finished for the day, it’s twenty to one and I need to be up at 6 to take the dog to paw stretchers. Fun fun.