what is this probe

[ME]

Hello,

(Sometimes I come across as being condecending, but this is not my intent. 
I may ask some questions that you have thought about before, bt it is not
to be unkind, but instead to make sure many of the basics are taken care
of. I have no way to know if you are an old hand at this stuff, or should
be asked "is it still plugged in" ;-) I know that my dealing with Frank E. 
Ball have been very positive on this list, and he has been very informed
in these on-line dicussions. The extra questions I ask in this case are
primarily listed as a reference for the new readers that might pass
through the same issues.)

I have some questions for you:

Are you using IP Masquerading?
 With a single interface that shares an aliased IP address and the real IP
address on the same port (eth0) ?

Example:
                 Host
          uplink |         
DSL ------------ HUB --- MASQ/GW/Router
                 |
                 Host

and if so, are you using a private network range with one machine that has
that specified source address?

(Probably something you have checked, but worth asking.)

Now...
I'll try my best to understand your log line:

(For more on what I write below, please see
http://www.linux.org/help/ldp/howto/IPCHAINS-HOWTO-4.html and jump down to
the section that starts with:  "Logging Packets" ) 

For ICMP (if the above page is still accurate) the "port" number listed
next to the src address is not a port number. For ICMP, it specifies the
ICMP type. For the dst port with ICMP, it is not a port, but the code. 

So, this would *suggest* an ICMP packet from SRC=172.31.105.12 to
DST=209.204.172.XXX with a code of 3, and a type of 13

Length is 56 butes (seems like a nice size to me ;-)

No need to worry about TOS (S=0x00) here

No worry about the IP ID (I=54743)

This packet has no fragmentation or framentation offset or flags.
(F=0x0000) (First 3 bits are the flags used, and the next 13 bits are for
the fragmentation offset.) No worry here.

TTL is fine (I guess. I understand the function of it, but it is zero
here) T=0 should not e a problem AFAICS.

and we can see that rule #3 (line 3) in your ipichains rule list is the
one that found this packet and logged it.

Now, using the above, and a nifty web page I put up based on RFC data on
ICMP, you can see what the type and code map out to.

http://libweb.sonoma.edu/mike/networking/icmppacket.html
(In the above link, I try to sum up the various inclusions of types and
codes for ICMP packets not listed in only RFC792, but also in RFC1122,
RFC950 and the 'TCP/IP Illustrated Volume 1' book.)

(Sample of the original RFC can be found: 
http://libweb.sonoma.edu/mike/macnc/rfc792.txt
for a specific review)