Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 3044 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

Firewall default drop of comms to remote SUM

stephen.mellor
Hi,

UTM: 9.207019
SUM: 4.2 (and 4.0)

I've set up a UTM at the same site as our SUM 4.2, deployed the various defs & rules to it, then moved it to its intended site with final tweaks to interfaces as required. All is well at the new site, except that the UTM cannot communicate with the (now remote) SUM 4.2. It can communicate with an older SUM 4.0 at another remote site (in legacy mode of course).

Both SUMs allow access from 0.0.0.0/0, and both are accessible to other UTMs we have at various sites.

The UTM can ping the SUM 4.2. None of the rules previously deployed to the UTM should prevent access to the SUM 4.2.

The UTM claims - 
[1] SUM SSL-connect: 'IO::Socket::INET6 configuration failed'.


The UTM firewall log shows - 
2014:10:02-11:32:20 eputm001-1 ulogd[7020]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth1" srcmac="0:1a:8c:f0[:D]7:41" srcip="10.240.78.148" dstip="10.240.68.41" proto="6" length="60" tos="0x00" prec="0x00" ttl="64" srcport="37060" dstport="4433" tcpflags="SYN" 

- where 10.240.78.148 is the WAN interface and 10.240.68.41 is the remote SUM 4.2

I'm fairly new to Sophos products, but it seems to me that the UTM is default dropping traffic to the SUM 4.2, despite there being rules in place to allow such traffic, both in the rules previously deployed to the UTM, and in a temporary user-defined rule (any/andy/any).

So, I'm a bit puzzled by this. I'd like to wipe the UTM and start afresh from a bare-metal install, but it's now in use and at a remote site, so I'd prefer to fix it in the background if at all possible.

Any suggestions?

ps This is a fully routed scenario - there's no NAT involved.


This thread was automatically locked due to age.
Parents
  • 0
    Are you using IPv6 in the SUM 4.2?

    "60003" means a drop out of the OUTPUT chain.  What happens if you replace your any-any-any rule with 'External (Address) -> {4433} -> {SUM 4.2} : Allow'?  In fact, I suspect a glitch in the 'Central Management' configuration' in this box, but I can't guess what it might be.

    Cheers - Bob
Reply
  • 0
    Are you using IPv6 in the SUM 4.2?

    "60003" means a drop out of the OUTPUT chain.  What happens if you replace your any-any-any rule with 'External (Address) -> {4433} -> {SUM 4.2} : Allow'?  In fact, I suspect a glitch in the 'Central Management' configuration' in this box, but I can't guess what it might be.

    Cheers - Bob
Children
  • 0 in reply to BAlfson
    Thanks for the response Bob.

    I'm not using IPv6 at all - it's disabled globally. I enabled it briefly, then disabled it, to see if that would perhaps clear some flags - no change.

    I tried a more specific rule for SUM comms - allow 10.240.78.148 to 10.240.68.41, port 4433, logging - no change, firewall log still shows traffic being default dropped.

    I updated the firmware to 9.207-19 - no change.

    I saved and reloaded the configuation - no change. Really clutching at straws here!

    I'm glad you think it might be a glitch - I was wondering if I'd missed something obvious. I have a couple of spare 220s and I think I'm going to have to take a trip to the site to build a new pair from scratch.
  • 0 in reply to stephen.mellor
    Fixed it!

    And it was something obvious, I couldn't see it for the life of me but Bob you kinda pointed me in the right direction...

    I looked again at the network definition I had for SUM 4.2, and under Advanced Settings the interface was set to 'internal'. I don't know how that came to be the case originally, but setting it to 'any' has fixed it.

    ~phew~