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

Interesting Observation with SUM4

tuscani
We have a SUM4 server and the devices we manage (external clients) reporting having our public IP as their public IP.. yet the agent IPs are correct. Let me explain..

Our Public IP 1.1.1.1 subnetted with /29
We have a public useable block 2.2.2.0/26 which are additional addresses on WAN\eth1 where 1.1.1.1 is of course defined. 

Our ISP routes the useable 2.2.2.0/26 block to our 1.1.1.1 public IP. 

The SUM server sits in a 3.3.3.0/24 DMZ which is NAT'd behind an address on 2.2.2.0/26. We'll say .10

All external devices we manage for clients point to DNS name sum.ourcompany.com which resolves to 2.2.2.10. 

What I do not get is when I look at the details on the devices it shows:

IP Address (Agent) devices actual public IP
IP Address (Public) our 1.1.1.1 public IP

This of course presents a problem as we end up hitting our webadmin instead of theirs from SUM... lol

To make things more confusing, of the 14 devices in SUM, only 12 have this issue.. yet all the devices have the same central management settings. 

Thoughts?


This thread was automatically locked due to age.
  • 0
    Something must be different about those machines then, are they on a different version? 
    Do they have different services enabled? 
    Does the ACC log shed any light on this? 

    If you traceroute from those machines that don't have the issue to 8.8.8.8 and did the same thing from the machines that do have the problem and you compare the output, is there a difference? As far as I can tell from what you've said they should be identical aside from response times.

    Can you run SUM or WebAdmin on an alternate port to solve the issue? If not, why not?

    Would it be possible for you to draw a network diagram? I find that diagrams often help me to understand non-trivial networks better than trying to sketch them in my head.
  • 0
    Ok first of all:

    If you have 


    Our ISP routes the useable 2.2.2.0/26 block to our 1.1.1.1 public IP. 


    Your normaly shouldn't have to do that:


    [...] which are additional addresses on WAN\eth1 where 1.1.1.1 is of course defined. 


    The packets for 2.2.2.0/26 are already routed to 1.1.1.1 by the provider, so you dont have to convince the provider's router to do that by answering arp-requests.

    Having said that, i have to admit, that what i've written above should  NOT lead to the problem you described. (But i would nevertheless give it a try by disabling the additional address)


    The SUM server sits in a 3.3.3.0/24 DMZ which is NAT'd behind an address on 2.2.2.0/26. We'll say .10


    Your problem could arise from doing FULL NAT instead of DNAT in NAT rules. (But only if you set 1.1.1.1 as "Change the source to:")



    IP Address (Agent) devices actual public IP
    IP Address (Public) our 1.1.1.1 public IP

    This of course presents a problem as we end up hitting our webadmin instead of theirs from SUM... lol
    [...]


    In the meanwhile there is a Workaround:
    You can configure SUM to use Agent-IP instead of Public-IP via 
    Management -> Registration -> *Device* -> Edit -> SSO Mode


    Kind regards
  • 0
    Thanks guys.. the workaround works great.. I can't disable the 2.2.2.10 additional address (public IP for SUM) because that's what remote devices outside our network connect to SUM with. I am already using DNAT. The NAT rule is:

    Any > ports 4433 and 8080 > 2.2.2.10 > 3.3.3.x address (inside DMZ)

    I still have to check the acc logs.. will report back