Hi Tim,
I have no idea what I have been doing wrong but it seems like the packet-filter just doesn't work for me. Finger trouble I'm sure. It produces a report containing the matches (and marking them accordingly) but it's still among a sea of noise. Here's what I've got in my config for that:
traceoptions {
file DebugTraffic size 10m;
flag basic-datapath;
packet-filter MatchTraffic {
protocol icmp;
destination-prefix 8.8.8.8/32;
source-prefix 192.168.1.2/32;
}
}
Anyway, further testing today and I discovered that my computers were resolving DNS, which means they were definitely making some sort of contact with my ISP's DNS IPs. So out of blind luck, I figured I'd try typing in www.google.com in my web browser and lo and behold, it worked. However, none of the websites I clicked on from Google worked. Odd.
I did a little more searching while Google was still working and found that someone else had tried to set one of these up with their TPG service. It turns out the maximum TCP segment size needed to be set and for good measure, I decided to do the MTUs as well.
So I've added these two settings in the [security flow] section:
tcp-mss {
all-tcp {
mss 1420;
}
}
tcp-session {
rst-sequence-check;
}
Everything sprang to life after that. Even my VoIP telephone, which I didn't need to open any ports for, I'm guessing thanks to stateful inspection and having the fairly relaxed trust-to-untrust NAT rule set established.
That said though, I still can't do any ping tests to the outside world. If I try to ping 8.8.8.8 or anything else for that matter, it still fails. As far as I can tell in the show security flow session, and if I'm interpreting the trace log correctly, it's blocking the pongs after the pings got out but I can't understand why if my configuration seems fine compared to others?