Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 2 subscribers
  • Views 3520 views
  • Users 0 members are here
Options
Suggested
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

dropped packets yet NAT rule exists...

dspender
Dropped Packet:
Some examples:


06:18:31 Default DROP TCP 205.234.170.163 : 38520 
 → 67.108.100.105 : 80 
 [ACK FIN] len=52 ttl=54 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:15:17:8a:fb:75 
 
10:34:26 Default DROP TCP 65.73.171.197 : 60921 
 → 67.108.100.105 : 80 
 [ACK RST] len=40 ttl=116 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:15:17:8a:fb:75 

12:32:06 Default DROP TCP 65.73.171.197 : 61352 
 → 67.108.100.105 : 80 
 [ACK FIN] len=40 ttl=116 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:15:17:8a:fb:75 
 
12:40:50 Default DROP TCP 170.122.200.58 : 58539 
 → 67.108.100.105 : 80 
 [ACK FIN] len=52 ttl=52 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:15:17:8a:fb:75 
 


NAT Rule:

Traffic Source: Any
Traffic Service: HTTP-HTTPS (predefined group)
Traffic Dest: Server-PUB (67.108.100.105)

DNAT

Dest: Server (10.1.1.182)

Web browsing traffic works fine, web page shows up, but I wouldn't expect to see ANY port 80 traffic in the packet filter log since its all specifically allowed.

What would be causing this?


This thread was automatically locked due to age.
  • 0
    Try to simplify your rules. I always try to keep my server publishing rules seperate from my regular web surfing rules. It creates extra rules but you don't break web surfing while trying to fix your published server and vice versa.

    So, just create a dnat to  10.1.1.182 and either check auto packet filter or create a packet filter for 10.1.1.182 ->ANY->HTTP/S allowed. You can also enable the logging on rules to see what rule worked and what failed instead of just the default drop like you are noticing now in packet filter log.
  • 0 in reply to Billybob
    Bill, aren't you thinking about this backwards?  Isn't he talking about browsing from outside, hitting the External IP and being successfully connected with the server behind his Astaro?

    Are these packets from outside dropped because they appear to be responses to connections from the Astaro, but conntrac has no record of them? I don't know what ACK FIN and ACK RST messages are for.

    Cheers - Bob



     - Bob
  • 0 in reply to BAlfson
    Yeah, to clarify:

    This is server that runs a web interface to an email server. It is functioning normally. That is, requests are coming from external IPs and being DNATed successfully (without being blocked I assume).

    I believe the packet log is showing traffic from a 3rd party external monitoring service we recently setup. I checked the service and it is set to check HTTP/80 on this certain web server but is failing. I would imagine that the blocked packets are why.

    Its interesting to note that 4 of our other webservers are not failing when checked by the service and they have the same DNAT setup.
  • 0
    I think this would be worth submitting a support ticket.
  • 0 in reply to BAlfson
    Sounds like conntrack is screwing up.
  • 0 in reply to BAlfson
    I think this would be worth submitting a support ticket.


    will do! 

    (apparently posts need to be more than 10 characters so i'm writing this extra stuff blah blah blah)
  • 0
    When you discover the solution, please post it.  I think utm_kid has had a similar issue testing the 7.5 beta.

    Cheers - Bob
  • 0 in reply to BAlfson
    UPDATE:

    Applied latest 7.405 update and rebooted along with making sure none of the definitions were assigned to any interfaces. 

    Problem still exists.

    Its currently being looked at by 'developers'.