static IPs not being routed to if idle

[doctorfb]

I have a problem that started about November 15th of last year (2012) and it's been a constant problem ever since. I have a block of 4 Sonic static IPs and I run 2 physical hosts and 2 virtual hosts. Each host has a unique IP from the block of 4 static IPs and each host has a unique MAC address. I have an internal network and the firewall is a NAT for all hosts inside. One of the virtual hosts runs a dedicated firewall and the other runs a dedicated web/ftp server and is only addressable via the static Sonic IP. Even the internal network can only get to it via the IP address. It's the web/ftp host that I'm having the problem with, which is this:
If the host doesn't see any network traffic for about 6 minutes, it becomes unaddressable by any external host on the internet. Once this condition occurs, the host must ping out to an external host in order for traffic to reach the host once more. I have a script that pings the Sonic-side router every 3 minutes, but this is less than ideal and defeats the purpose of having static IPs in the first place, plus this wasn't necessary before November, and this wasn't a problem previously up until May when I started using the Sonic Fusion service and got the block of 4 IPs originally.
I have contacted Sonic Tech Support and described my problem. The tech consulted with a senior tech and stated that the "host keeps dropping off" and "because I'm running VMware hosts", but couldn't explain what any of that ment. After some digging, I believe he is refering to the ARP cache that all network devices maintain for peer connections. The ARP cache contains host IPs and their MAC addresses and are designed to age and drop these entries at a regular interval (usually 60 seconds), unless there is activity seen to or from the host address. I suspect this is what the tech ment (I haven't confirmed this), so this is just speculation on my part.
But, this doesn't make sense to me. With static IPs all network packets for those 4 IPs should always be routed to/through my DSL router to whatever hosts I happen to have running those IPs, virtual or otherwise.
Now, it so happens that this same host was hacked back in October and the attacker started doing something with it that caught my attention on November 13th. As of the 14th, I'd wiped the host and re-created the host image from scratch, so there was no possibilty of anything left over from the exploit. And that's when this timed unaddressability issue started.
I'm in a bit of a quandry. I've searched all of the Sonic Blogs and status/events and can't find anything even close to November that seems like a relevent change that might explain this change.
Has anyone else seen anything like this happen?

[aw]

This thread has great information on how Fusion circuits handle ARP:
viewtopic.php?f=10&t=120&hilit=arp

Different firewalls will have different ways of handling this. I use pfSense, and on fusion circuits I have to add the IPs as CARP addresses instead of Proxy ARP to get around the issue.

[doctorfb]

This thread has great information on how Fusion circuits handle ARP:
viewtopic.php?f=10&t=120&hilit=arp

Different firewalls will have different ways of handling this. I use pfSense, and on fusion circuits I have to add the IPs as CARP addresses instead of Proxy ARP to get around the issue.

Greetings, aw,
Thanks for the threads. I run one NAT for my internal machines, but the other three are directly attached "hosts" (all of which run a software firewall to prevent nasties from attacking, all configured "correctly" (passing the good ICMP packets, blocking the malicious ones). I even briefly disabled all firewall activity while I probed the problem, to no avail.
After reading that thread (and the others included in that one...not sure how I missed them in my searches) it appears I arrived at the same conclusion (and "solution") as everyone else.
What puzzles me is that this was not an issue before November (a period of about 7 months from when Fusion was installed). I'm positive that several of my hosts (virtual and physical) had long periods (Hours) of no network traffic, and yet were immediately addressable without them having to do any ARP discovery (beyond the initial gratuitous ARP caused by bringing the interface up). Or, perhaps I'm mistaken and they were receiving/sending enough traffic to keep the ARP cache active. Hmm! Maybe there is a benefit from the script kiddies always banging on our hosts after all! (just kidding
One thread mentioned that Sonic "solved" the problem for him by:
"Yes, Sonic added a static MAC address for each of my IP's and the problem is solved!"
viewtopic.php?f=10&t=120&hilit=arp&start=10
When I was using the Legacy DSL service (been with Sonic for a very long time, btw) I remember giving Sonic the MAC for one of my hosts initially (the one I used initially to connect to Sonic's website and request static IPs). Back then I also had about 4 hosts using static IPs and they were always addressable.
I recall asking the Sonic service tech who installed my new DSL modem/router, for the Fusion service, and I don't remember him saying I needed to do that this time. Now I'm wondering if I can give the MACs for my hosts to Sonic to solve my problems?
Anyway, thanks again. For the time being, I have my "solution" in place.

[doctorfb]

Unfortunately, it appears, my "solution" is not working satisfactorily. My IP still appears to be unaddressable for long peroids of time. My script was checking my local arp cache every 120 seconds to see when the sonic router's entry disappears and do then do the arping, assuming that the caches would timeout at about the same time. It appears this is not the case. I'm now resorting to always arping every 60 seconds. I feel this is wasteful and really should not be necessary given I'm paying for static IPs. I really want a better solution.
This is very frustrating.

[doctorfb]

After some more digging, it looks like I need to make some changes to my ZyXEL DSL router. I've found the following Sonic wiki article describing Static IP setup here:
https://wiki.sonic.net/wiki/Zyxel_P-663HN-51
However, the instructions just don't make sense to me.
It says to:
enter your static IP information in the "WAN IPv4 address" field
I have a block of 4 static IPs. Does this mean I'd have to pick one of those to assign to the WAN interface? I don't actually want the router to be directly addressable from the 'net. It's supposed to be a transparent bridge between WAN and LAN. I want the devices on the LAN side to be addressable with those IP addresses. But, if it will make it so that the Sonic side doesn't keep dropping my MAC routing, I guess it's worth it....
Hmm.... more research is needed.

[klui]

I have a block of 4 static IPs. Does this mean I'd have to pick one of those to assign to the WAN interface? I don't actually want the router to be directly addressable from the 'net.

Most likely you need some machines NATed and they'll go through the router's IP. Other machines you want at your edge use your remaining IPs.

[doctorfb]

I do, infact, use one of the IPs a a NAT for my local networked machines, while two other IPs are effectively my public-facing machines (web/ftp/email), with a 3rd reserved for occasional external testing. But the problem is that none of these IPs remain addressable by internet hosts unless they, themselves, generate outbound traffic first and on a contined regular basis (which has now dropped to about 60 seconds).
I do not believe assigning any of the IPs to my DSL router would improve things since it's clearly a case of Sonic's router not routing requests over to my side of the line. If I am wrong on this, then someone needs to explain to me exactly why.
As I've said, this was a sudden change back in mid November with no warning and little in the way of explaination from Sonic's support staff, or perhaps, I should say, an "explaination" that doesn't really explain anything at all.
This is very disconcerting since I've been with Sonic for many years, through 2 house moves, and never had this, or really much of any, kind of problem before with Sonic's service.
Until I get a resolution I have an active ping going from all "hosts", once per minute.

[waynesung]

Do you have any ethernet switches involved which discard packets with unknown destination mac addresses, i.e. the addresses have timed out from the switch mac table? That's what happened to me once.

[doctorfb]

Nope, no additional switches involved, just the built-in switch in the ZyXEL itself. All hosts are directly plugged into the ZyXEL LAN ports. But, if the built-in router didn't work, then nothing would work. I haven't been able to determine where the routing problem is, exactly (I'm just guessing). I'm presuming the problem is over on the Sonic side of things since it appears they are not sending packets to me. However, I can't really tell if packets are being dropped over there or dropped over on my side. I don't see a direct way to snoop packets coming over the bridge. The ZyXEL manual doesn't seem to provide a way of doing that. I do know that I'm not seeing any route discovery packets being sent to any of my hosts, which is suspicious. Also, the stats for the DSL links show very high error rates in one of the status pages (I don't remember which one, I'll have to look at that again).
It's all a bit frustrating.

[waynesung]

>I can't really tell if packets are being dropped over there or dropped over on my side.

I have a modem that only converts the dsl to ethernet and a separate router to do the rest. This wasn't specifically for packet monitoring but the connection between the two would allow the verification you want.