I have the same behavior with Videotron here in canada. a power off for 2-3 minutes does the trick everytime.
On Sat, May 10, 2014 at 10:58 PM, Aaron C. de Bruyn <aa...@heyaaron.com>wrote: > Good to know. > > Slightly OT, but why would they have ARP cache timeouts of four hours? > What benefit do you get with such high cache times as opposed to the > obvious support calls you will get when equipment is swapped around? > > -A > > > On Sat, May 10, 2014 at 7:55 PM, Moshe Katz <mo...@ymkatz.net> wrote: > >> On Fri, May 9, 2014 at 10:56 PM, Aaron C. de Bruyn <aa...@heyaaron.com>wrote: >> >>> Spent about an hour beating my head against the wall with this issue, >>> hopefully this will save others some time. >>> >>> We had a stand-alone pfSense router. >>> We just purchased two machines from ixsystems and were preparing them to >>> be a failover pair of pfSense routers and then decommission the smaller >>> older box. >>> >>> While we were installing the new servers, the HDD in the old firewall >>> died. >>> >>> We figured we would just get the two new boxes up. >>> >>> Plugged them into the Comcast modem and configured everything. >>> >>> Comcast assigned us a /28 a while back and we were using a handful of >>> IPs to access various internal services over HTTPS. >>> >>> The /28 looked roughly like: >>> .1 - router1 >>> .2 - router2 >>> .3 - exchange (CARP) >>> .4 - remote (CARP) >>> .5 - VPN (CARP) >>> .6 - spamfilter (physical machine) >>> ...etc >>> >>> After everything was configured, I had someone test remotely that they >>> could access the interface for router1 and router2 remotely. >>> >>> I then went home to finish up a few config details remotely. >>> >>> When I got home, I found I could access router1 and router2 as well as >>> the physical spam filter, but I couldn't access any of the HTTPS services >>> on the CARP IPs. >>> >>> I checked my NAT rules about 100 times, looked through firewall logs, >>> and found nothing. >>> >>> Finally I connected in to the spam filter (linux box) and ran 'openssl >>> s_client -connect exchange.example.tld:4433' and noticed it worked >>> perfectly from a machine on the same WAN segment. ...but not remotely. >>> >>> I called Comcast and had them remotely reboot the modem. Everything >>> immediately came up and started working perfectly. >>> >>> Hopefully this will save someone time. Reboot the brain-damaged Netgear >>> CPE after swapping hardware around. >>> >>> -A >>> >> >> Hi Aaron, >> >> Most cable modems I have worked with in the US (on Comcast, Optimum, and >> RCN) all do ARP caching, so you need to reboot them when you change the >> connected device (or you need to clone the old device's MAC address). >> >> Actually though, working with DSL is worse. Verizon DSL does ARP caching >> in the Central Office for up to four hours. I have found that replacing >> equipment hooked up to Verison DSL, it is best to already be on the phone >> with Verizon support to have them manually clear the cache. At least >> rebooting the cable modem is something you can do yourself. >> >> Moshe >> >> -- >> Moshe Katz >> -- mo...@ymkatz.net >> -- +1(301)867-3732 >> >> _______________________________________________ >> List mailing list >> List@lists.pfsense.org >> https://lists.pfsense.org/mailman/listinfo/list >> > > > _______________________________________________ > List mailing list > List@lists.pfsense.org > https://lists.pfsense.org/mailman/listinfo/list > -- Alexandre
_______________________________________________ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
