Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 41 subscribers
  • Views 8546 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

Cant get a simple directly connected network firewall rule working. XGS126

PeteH

I am completely stumped by this.  I am sure its something obvious that I am overlooking. 

Lan Port 1 - 192.168.1.254/24

MGMT port 5 - 172.16.0.254/24

I already had a rule saying mgmt subnet source 172.16.0.0 could access lan subnet destination 192.168.1.0.   That worked fine, the mgmt server (172.16.0.1) can RDP etc to the LAN server (192.168.1.250).

but then the server engineer said could I allow access from mgmt server to the LAN server ilo (192.168.1.251).   First off I couldnt work out why this wasnt just working with the above rule.

So set up a separate rule above the other one just for mgmt server to lan server ilo but when I ping or try access it it doesnt work. I can see the out counter slightly increasing on the rule.  

In the firewall logs I can see the rule being hit and being allowed. 

What am I missing?  I know the ilo is working fine as it is reachable from the lan network server so ive got past it being a physical (cable, connection) issue.



This thread was automatically locked due to age.
Parents
  • +1

    Hi  Can you please check CLI TCPDUMP on the firewall for the destination server IP 192.168.1.251 to see if we are getting an ICMP reply while you are checking PING from the MGMT server?

    console> tcpdump 'host 192.168.1.251 and proto ICMP
    console> drop 'host 192.168.1.251

    If the Firewall is forwarding packets out to Port1 (LAN zone interface) and there is no reply back from the LAN server and no drop packet on the firewall with the above command then try with a separate rule by creating a link NAT rule with MASQ action to see how it goes or if the separate rule is already added by you for specific source and destination then crate link NAT rule for that firewall rule with NAT action MASQ.

    After that check TCPDUMP and drop again with the shared command above..!

    Regards,

    Vishal Ranpariya
    Technical Account Manager | Sophos Technical Support
    Sophos Support Videos | Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts |
    If a post solves your question use the 'Verify Answer' link.

  • 0 in reply to Vishal_R 
    console> tcpdump 'host 192.168.1.251 and proto ICMP'                            
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode      
    listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 byt
    es                                                                              
    13:25:00.682319 Port5, IN: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id 
    1, seq 73, length 40                                                            
    13:25:00.682680 Port1, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id
     1, seq 73, length 40                                                           
    13:25:00.682686 mv-pcimux0, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo reques
    t, id 1, seq 73, length 40                                                      
    13:25:05.467696 Port5, IN: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id 
    1, seq 74, length 40                                                            
    13:25:05.467823 Port1, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id
     1, seq 74, length 40                                                           
    13:25:05.467828 mv-pcimux0, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo reques
    t, id 1, seq 74, length 40                                                      
    13:25:10.465974 Port5, IN: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id 
    1, seq 75, length 40                                                            
    13:25:10.466047 Port1, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id
     1, seq 75, length 40                                                           
    13:25:10.466054 mv-pcimux0, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo reques
    t, id 1, seq 75, length 40                                                      
    13:25:15.466716 Port5, IN: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id 
    1, seq 76, length 40                                                            
    13:25:15.466774 Port1, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id
     1, seq 76, length 40                                                           
    13:25:15.466778 mv-pcimux0, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo reques
    t, id 1, seq 76, length 40   

                                 
Reply
  • 0 in reply to Vishal_R 
    console> tcpdump 'host 192.168.1.251 and proto ICMP'                            
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode      
    listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 byt
    es                                                                              
    13:25:00.682319 Port5, IN: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id 
    1, seq 73, length 40                                                            
    13:25:00.682680 Port1, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id
     1, seq 73, length 40                                                           
    13:25:00.682686 mv-pcimux0, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo reques
    t, id 1, seq 73, length 40                                                      
    13:25:05.467696 Port5, IN: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id 
    1, seq 74, length 40                                                            
    13:25:05.467823 Port1, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id
     1, seq 74, length 40                                                           
    13:25:05.467828 mv-pcimux0, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo reques
    t, id 1, seq 74, length 40                                                      
    13:25:10.465974 Port5, IN: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id 
    1, seq 75, length 40                                                            
    13:25:10.466047 Port1, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id
     1, seq 75, length 40                                                           
    13:25:10.466054 mv-pcimux0, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo reques
    t, id 1, seq 75, length 40                                                      
    13:25:15.466716 Port5, IN: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id 
    1, seq 76, length 40                                                            
    13:25:15.466774 Port1, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo request, id
     1, seq 76, length 40                                                           
    13:25:15.466778 mv-pcimux0, OUT: IP 172.16.0.1 > 192.168.1.251: ICMP echo reques
    t, id 1, seq 76, length 40   

                                 
Children
  • 0 in reply to PeteH

    Ive just put Masq on the separate rule and now the traffic is working.  Can you explain why masq nat is needed for that rule but not the main MGMT subnet can access the Lan subnet fine?  Thats is really confusing to me.

    thanks

  • +1 in reply to PeteH

    Hi  In the above-shared captures I have noticed that for request packets generated by source 172.16.0.1, no ICMP reply from destination IP 192.168.1.251 was received back.

    Also during our packet "Port1, OUT: IP 172.16.0.1", the original IP is there and no MASQ has been tried as per the shared suggestion earlier.

    Would you please create a separate rule for the above source and destination IP on top along with the linked NAT rule with NAT rule action MAQS and try to check the status again..! 

    Regards,

    Vishal Ranpariya
    Technical Account Manager | Sophos Technical Support
    Sophos Support Videos | Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts |
    If a post solves your question use the 'Verify Answer' link.

  • +1 in reply to PeteH

    Requested explanation: This confirms the reply from server 192.168.1.251 was not coming back when source 172.16.0.1 was communicating with its original IP, MASQ will change the source IP to Port1 Interface IP for out direction packet - which is of the same network as the end server source 172.16.0.1 and due to same network it seems server replied to ICMP request and fixed your PING issue. 

    Regards,

    Vishal Ranpariya
    Technical Account Manager | Sophos Technical Support
    Sophos Support Videos | Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts |
    If a post solves your question use the 'Verify Answer' link.

Unfiltered HTML