Posts Tagged problem

Fixing Static Addresses on Verizon FIOS

Verizon has a bug in their business offering for multiple static IP addresses.

When using a professional firewall that such as a Cisco ASA, I could only get 1 address to respond from offsite.

The first problem was solved by going to, you have to call Verizon and convince them to instant message the group that runs the ONT’s (the termination that is onsite) to set the MAC filter to 5.

After that only 1 IP address worked per device. I could ping each other but Verizon served traffic could not see me. A quick TCP-Dump of the external segment showed the problem:

arp who-has (00:1e:4a:87:32:59) tell
arp who-has (00:1d:70:26:3c:53) tell

The address is slightly illegal, the ASA ignores the ARP request and the Verizon gateway never binds the Mac to the translated IP addresses. This means that inbound static addresses didn’t work and only the physical interface address could be used for the outbound global pool.

I managed to get Verizon to admit the bug, the Alcatel equipment was partially to blame and I would imagine that the (non-professional) “firewall” that comes with the account had been modified to respond to an ARP request from They projected it would be fixed Q1 of the next year… that was 15 months ago.

I found that the service (that I am paying for) could be made to work. I adapted a short Perl script to send ARP replies to the Verizon gateway router every 30 seconds or so, as if it was responding to an ARP request.

arp reply is-at 00:1d:70:26:2c:53

Here I am telling the gateway that .36 is bound to the same address as .35. I was immediately able to ping the address .36 remotely, alls it took was a Linux system and the perl script below. I don’t believe that the ARP replies can be generated inside the ASA and be made to traverse the firewall; several types of lower traffic can using the ethertype command but ARP’s get absorbed. I haven’t tried proxy-arp to see if it relays the bogus advertisement as it breaks so many rules of paranoia that I doubt that the ASA would propagate it.

At the moment I have plugged in a dedicated Ethernet interface from my VMWare stack and am running a virtual Linux machine for the sole purpose of “poisoning” the ARP table. The FIOS service itself screams, though we wouldn’t ever consider using their DNS, but leave it to Verizon to pull up short on static IP address support.

Bil Herd

use Net::ARP;
use strict;
use warnings;
for (;;){

‘eth0’, # Device
‘’, # Verizon gateway, not really of course

‘’, # address that we want Verizon to respond

’00:1E:EC:9F:DB:67′, # Source MAC Mac of our address

’00:1d:70:26:cc:53, # Destinaton MAC address for ARP
‘reply’ # ARP operation
print “packet sent\n”;

To install the Net::ARP module using CPAN:

perl -MCPAN -e ‘install Net::ARP’


, , , , , , , , , ,


QM FSM error

Getting “QM FSM error” while establishing a Cisco VPN?  Particularly site-to-site and even more particularly with IOS on one end and a Pix/ASA on the other?

Go to the Pix/ASA side and remove Perfect Forward Secrecy (PFS).  Rather than tell you it’s incompatible, it just barfs because it can’t read it (because it’s you know… encrypted).

no cryptomap outside 1 set pfs group2

If anyone finds a better error message than the ubiquitous “QM FSM error” let me know and I will post it.


, , , , , , , ,


Blocking ICMP

This is old news, real old, but I still run across it from time to time.  Customers block ICMP in their firewall or other places.

Internet Control Messaging Protocol is more than just ping (I remember the early Mac’s didn’t implement ICMP or at least echo/ping in their IP stack).

ICMP among other things tells equipment up and down the line a few interesting things, not least is when they need to fragment a packet into smaller packets.  Symptoms range from telnet or web works and email or ftp don’t, some of the time.  In short to the casual observer (known as a user), it is one more thing that works randomly.

Nowadays it’s more important then ever with the proliferation of VPN’s,  to get your fragging done as thoroughly as possible, before the packet gets sucked into the VPN terminus.  Why?  You cant fragment an encrypted packet, in fact it’s not even TCP (IP Protocol type 9) anymore it is type 50/ESP or type 47/GRE, and because it’s encrypted you really cant bust it into smaller parts and calculate checksums, etc.

Exchange clients don’t work on all workstations across VPN’s?  There were various versions of MS patches hat appeared to break the MTU discovery mechanism that says use smaller packets.


, , , , , , , , , ,

No Comments

PDM to Cisco Pix not working

First pointed out to me by my tech Rob, some of the Cisco PIX/PDM combinations won’t make a connection on the outside interface in spite of being properly configured.  Try SSH ing to the external interface anc check the PDM again.  I have seen this almost half a dozen times in the last couple of years, the last was PIX software version 6.3(5) running PDM 3.0(1).


, , , ,

No Comments