Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 3 subscribers
  • Views 1640 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.
Parents
  • 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
Reply
  • 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
Children
No Data