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

ARP problem on an WAN interface with additional IP addresses

Hello UTM bubble,

I have a problem with an WAN interface with additional IP addresses and i hope you have an idea how to solve it without help from ISP or extra router in front of UTM.

Following setup i made:
The ISP gave the customer a fixed IP, but this IP i just can obtain if i am doing DHCP on the ethernet interface.
Well, i can set it fixed, but then the access to the ISP network just works for a few days, since their DHCP is used to register the customers machines.
However, the ISP gives back the IP with a netmask of /22.

Additional the customer got 8 more IPs for using, that aren't inside the given /22 Net.
I configured them as additional adresses with /32 netmask.

I made some WAF configurations with this addional IPs and used some for DNATs.

Now the problem, that i can't solve:
Whenever a client from WAN comes with an source IP within the given Network at primary interface (within the mask /22) and is talking with one of the additional IPs, there is no connection. When i made a tcpdump on the interface, i saw, that the ARP request is coming from the additional IP instead from the primary address and this ARP isn't answered within the ISP network.
The actual workaround for them is, that the user is doing an ping to the primary address and then the arp table on the UTM is filled with correct values and a communication with the additional IP address is possible for a while.

Example to visualize:
Lets say eth1 has IP 1.0.0.2/22 with additional address 2.0.0.1/32
Client 1.0.0.3 is trying to reach 2.0.0.1:443
UTM is asking: "ARP, Request who-has 1.0.0.3 tell 2.0.0.1, length 28"
This one is never answered.

Network communcation for all clients outside of this given ISP Network are doing well.

Addtional question:
As for the same reason of this huge network on ISP side, all services on other WAN interfaces of the UTM aren't usable by clients within that network, since the UTM always want to send answer packets out of the interface thats connected to the ISP network. Any ideas, to prevent that and bypass the interface routing, since i didn't found a solution with UTM ressources. Only way i see is to setup another router between ISP router and UTM. But that i wanted not to do.

Thank you in advance.



This thread was automatically locked due to age.
Parents
  • Hallo Arnold and welcome to the UTM Community!

    Unlike many other manufacturers, the Sophos UTM does not need to have an interface configured with the subnet including the default gateway.  All Additional Addresses should be configured with a /32 to avoid creating routing problems as you have done.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hello Bob, nice to read from you. You are the UTM Hero of this Forum for years :)
    Yes, I know about the /32 for additional addresses, it was the first thing I learned about Astaro back in 2009, when i started to work with.
    Thats the cause i was very confused, that the ARP request wasn't going from the expected IP.

    But i wrote a bit above, that we got the problem solved with the provider itself.
    They noticed that there is a general problem with their Routing and ACLs, so they changed the primary adress that are given by their DHCP Servers to an /32 too. Now we don't have any problems with it anymore, since there is no need anymore for ARP requests to other customer of this provider.

Reply
  • Hello Bob, nice to read from you. You are the UTM Hero of this Forum for years :)
    Yes, I know about the /32 for additional addresses, it was the first thing I learned about Astaro back in 2009, when i started to work with.
    Thats the cause i was very confused, that the ARP request wasn't going from the expected IP.

    But i wrote a bit above, that we got the problem solved with the provider itself.
    They noticed that there is a general problem with their Routing and ACLs, so they changed the primary adress that are given by their DHCP Servers to an /32 too. Now we don't have any problems with it anymore, since there is no need anymore for ARP requests to other customer of this provider.

Children
No Data