"destination: WAN"
Hi, you're using WAN Address in the Destination, right?
"I can see the inbound traffic passing the DNAT rule, but it never hits the firewall rule."
I'm not sure what you mean by this, but if you have the Auto PacketFilter Rule checked in the DNAT, then the traffic will be allowed by that rule, and your other packetfilter rule won't have any effect.
Are you sure there's no firewall running on the webserver?
You could run a sniffer (tcpdump is available on the Astaro shell).
Barry
I can only think of a few things that would cause the problem you describe:
- Whenever something strange happens, always check the Intrusion Prevention log for Anti-DoS Flooding activity or an IPS rule being triggered
- Check that the Host definition for the web server is not bound to an interface, but has 'Interface: >'
- As Barry said, check that you're using the "(Address)" object (created by WebAdmin when the interface was defined) in the traffic selector Destination, and not a Host/Network Definition that you created.
- Before the Firewall Allow rule, there's another one that silently drops this traffic
If you have the three right, try selecting the auto firewall rule in the DNAT - if that works, then your problem must be the last possibility.
Cheers - Bob
Thank you for the reply. as for IPS, I did see a bunch in there coming from the source IP, so I disabled while I was doing the testing. No difference
As for the source network, yep I used the any which was created by astaro.
The inbound rule looks like this any http destination host.
Whats weird is it replys on port 443 if I change the NAT and inbound rule to HTTPS.
Just a short note to say thank you to the both of you. It did turn out to be an IPS rule that was keeping it blocked. Once I created an exception for that host it was open. Thank you again
If the firewall is dropping your SYN ACK packet, it has already closed the conntrack entry for that connection before your internal machine can even respond to the ACK. My first guess would be that it is sending enough SYN packets in a short enough amount of time before your server responds which should cause the Sophos to kill the connection. I noticed in your testing that it appears you're using ShieldsUp to test the port being open. Is that true? While I use ShieldsUp sometimes to test specific ports being open from the WWW, I would caution using it in standard mode. This will trip the Sophos' portscan detection. It's important to note that this has to be disabled specifically. Turning IPS off still leaves Portscan detection on which will cause this test to fail.
Sorry, in the first line I meant to say that it is closing before your machine can respond to the SYN packet, not the ACK packet. Though I'm sure most people caught my drift.
