Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 3 replies
  • Subscribers 3 subscribers
  • Views 10389 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

STAS traffic is being dropped by UTM 9

S248

I logged a call with Sophos support 5 weeks ago now, and to date they still can't solve my problem. It's been through one guy who has assigned it to the "development team" and they still don't have an answer for me, despite constantly following them up. Anyway, enough about that I thought it's time to pose this issue to the wider community to see if anyone has any great ideas. 

I have an Amazon VPC IPSec VPN tunnel running to my VPC in AWS. In AWS I have a domain controller with STAS installed. The STAS application has its service running and STAS is configured, but the problem I have is when the packets come into the UTM from the domain controller to 10.50.1.1 (LAN address of the UTM) on UDP port 6060, the traffic is being dropped against the Default drop rule which is observed in the firewall logs. I have tried configuring a specific rule which says the domain controller can talk to 10.50.1.1 on port 6060, and I have even tried with an any any any rule, and the firewall logs still shows the traffic from the domain controller going to the UTM on port 6060 being dropped. Note that i can ping the UTM on 10.50.1.1 just fine. I've also completely ruled out windows firewall even though it's not really applicable here. 

Before this problem, i solved another problem where the UTM was using the Amazon VPC tunnel address (169.254.x.x) as the source address to talk to the domain controller, so i've created a source nat rule which translates traffic originating from the UTM going to the domain controller to be changed to the LAN ip address 10.50.1.1. If I don't do that, the return traffic from the domain controller never makes it back. 

Any ideas? 



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

    Finally got to the bottom of it. It comes down to this: 

    • When you specify the host object of your active directory server under the STAS config (Definitions and Users -> Client Authentication -> STAS), the host object you use must specify the interface, in my case i specified the internal interface - no surprise there and I had already done this anyway. Note if you try to add the host object here without an interface specified under the host object it won't let you add it anyway, so foolproof there. 
    • In the firewall rules, the trick here is to create ANOTHER host object of your active directory server and ensure you DONT specify an interface for this object - then allow this object to talk to the Internal (address) object on port 6060.

     

    The explanation for the second dot point, when you look into the packetfilter.log the packet is coming into vpc0.1, but if your firewall rule to allow active directory server to talk to the UTM on port 6060 has an interface specified in the host object, it won't get a match and will drop the packet as a result. In other words the UTM is only allowing traffic coming in eth1 instead of * (which is any). Therefore you need two separate host objects for the same active directory server. 

     

     

     

Reply
  • +1

    Finally got to the bottom of it. It comes down to this: 

    • When you specify the host object of your active directory server under the STAS config (Definitions and Users -> Client Authentication -> STAS), the host object you use must specify the interface, in my case i specified the internal interface - no surprise there and I had already done this anyway. Note if you try to add the host object here without an interface specified under the host object it won't let you add it anyway, so foolproof there. 
    • In the firewall rules, the trick here is to create ANOTHER host object of your active directory server and ensure you DONT specify an interface for this object - then allow this object to talk to the Internal (address) object on port 6060.

     

    The explanation for the second dot point, when you look into the packetfilter.log the packet is coming into vpc0.1, but if your firewall rule to allow active directory server to talk to the UTM on port 6060 has an interface specified in the host object, it won't get a match and will drop the packet as a result. In other words the UTM is only allowing traffic coming in eth1 instead of * (which is any). Therefore you need two separate host objects for the same active directory server. 

     

     

     

Children
Unfiltered HTML