![]() ![]() ![]() * The FVS338 Reference Manual has an entry for this, but I don't see it in the interface. Please see the manufacturer’s documentation for steps to check and update the software. Ensure your modem/router is using the latest software (firmware) for your particular model.If your 3G MicroCell is connected to a router that is connected to the modem and both the router and the modem have NAT (Network Address Translation) enabled, disable NAT either in the router or the modem.If you have multiple routers, 3G MicroCell must be connected to the first router connected to the broadband modem.I've tried both the default 15, without any change in behavior. MAC address filtering is either turned off or allowing MAC address of the 3G MicroCell.Port Blocking is either turned off or allowing ports 4500 and 500.I think the test results rule out a hardware failure, and I checked the security/firewall/rules sections of both FVS338 units, and they're identical, and running the same, up-to-date firmware version.ĪT&T publishes a Troubleshooting Guide, of which Section 2 has the following: I took the microcell to my office, which has another FVS338 and a T1 from Megapath, and the microcell works fine there (once I register the work street address at att.com). I believe the cabling is fine, both because I can plug my laptop into the same cable that feeds the microcell and get 20/5 from, and because AT&T _is_ getting a GPS match from the device itself. I spent more than an hour on the phone with AT&T performing rudimentary troubleshooting tests until I finally got escalated high enough for someone to tell me, "The microcell is updating us with its GPS location, which matches your street address, but then we're getting Error 202, which means 'Could not establish IPSec tunnel.'"Īll this same hardware worked fine for the previous 14 months, and I didn't change anything on my home network other than move a few patch cables around. The Power, Internet, and GPS light go solid after power-up, but the 3G light never stops blinking. I have FIOS 15/5 service at home, but I provide my own router (Netgear FVS338) instead of the ActionTec one because I want a hardware VPN tunnel back to my office.Ībout a week or so ago, my AT&T Microcell stopped working. If I keep the fw configuration very basic, it seems like it runs ok (though I haven't let it run for days w/o touching it – too much fun getting everything configured and exploring all the options, reports, etc).Īnyway, running the current build of 2.1, strongswan 5.1 on virtualbox.TL DR: Anyone else having recent problems with an AT&T Microcell over FIOS? Usually the port 4500 problem happens when I'm configuring rules/nat options. But otherwise it seems to be running fine. Did have to set the fw optimization to conservative in order to allow ssh traffic to not get "stuck", not sure what that's about. I've been running linux fw for years, and wanted to give pfsense a try. Verified using tcpdump on the console sniffing the wan adapter. When it breaks, pfsense is sending out the 4500 traffic with the internal source IP of my ipsec server instead of the WAN IP. Only difference is that I'm running strongswan/ipsec on a dedicated vm. I'm encountering what seems to be the exact same problem as the OP. Sorry for revisiting a slightly older post. I have a suspicion that UDP traffic to port 4500 is waking up some sort of IPSEC ALG code in pfsense which gets confused. A few days ago, I set up OpenVPN on pfsense using the wizard, and around the same time, outbound udp/4500 broke again. A reboot of pfsense did not fix the problem.įinally, I turned off automatic outbound rule generation, and created an explicit rule to NAT udp 4500 and moved the rule to the top of the list. ![]() After wiresharking the WAN side of pfsense, I could see that UDP packets headed out of pfsense destined to port 4500 were going out with the source IP set to the internal address of my microcell, instead of pfsense's public IP address. ![]() A couple of weeks ago, my microcell quit working. I did not do anything relating to the IP address of the microcell or port 4500. The only tweaking I did was playing around with traffic shaping rules to get my VoIP phone system working better. I had been running pfsense for several months with no problems at all. The device generating the outbound traffic to UDP/4500 is an AT&T microcell. The odd thing is that it starts doing this at random times, and a reboot does not fix it. At some point in time, pfsense will stop NAT'ing outbound udp packets going to port 4500, and instead send the packets out the WAN side using my internal IP address as the source. I've definitely found a bug in pfsense 2.1. ![]()
0 Comments
Leave a Reply. |