This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Need to stop blocking based on source port

Hi I have a web application that is failing and reporting that a [RST] packet is being sent from one of the devices in the connection chain. I suspect that this is the firewall and the failing service may correspond with a firewall log event (see attached). The log shows a random destination port but a standard source port (port 80). Is there any way of allowing traffic based specifically on it's source IP and port whilst ignoring the destination port? 

A sanitised version of the logs is attached

Thanks

JB


This thread was automatically locked due to age.
  •  

    any thoughts on this would be greatly appreciated chaps.
  • That's a remote webserver that's trying to reset a connection with something behind your Astaro.  It's strange that the destination IP is 192.168.168.254 - how could any public router think to send that to your Astaro?  In any case, allowing the traffic to pass would have no effect as the connection tracker wouldn't know where to route the packet.  Net-net, I think you have a different problem with your application.

    Cheers - Bob
  • That's a remote webserver that's trying to reset a connection with something behind your Astaro. 


    Is it Really? I had read that as being a packet sent from the remote web server 
     being dropped and then a subsequent reset being sent from the local web application server.

    the 192.168.168.254 id the external interface of the firewall. It (the firewall)is behind a NAT router itself - They only have one public IP which is held by the router. All packets are forwarded to the firewall's external interface and then blocking / forwarding is handled there.

    Does this shed any more light on this?

    Thanks for the reply Bob.

    JB
  • Yes, I mistakenly saw the RST on the same line with the drop, but the net is the same - even if you allow the packet, the Astaro has no idea what to do with it.  There might be more information in the complete log line with sanitized IP and MAC addresses, but I suspect that it only would confirm that the packet is being dropped out of the INPUT chain.

    Cheers - Bob
  • Thanks Bob. Cn you think of way we can get this traffic to go through, as it seems to be killing one of the functions of a SOAP connection?
  • Hi, the dropped RST may be a red herring; how long into the connection is that occurring?

    Barry