Invalid transport field for protocol=6?????? 1

[bubarooni]

I am getting this in my PIX log from a workstation that i want to access an Exchange server. The workstation (192.168.4.12) sits on one end of a site-to-site vpn and the Exchange server (192.168.1.222) sits at the other end (the end with the PIX).

The workstation is an IVR machine. The full error message in the log is:

<164>%PIX-4-500004: Invalid transport field for protocol=6, from 192.168.4.12/31775 to 192.168.1.222/0

The IVR vendor says that their machine needs ports 21,25,26 and 80. I am pretty sure I have traffice pretty wide open between the two subnets. I can ping the 192.168.1.222 machine from workstations on the 192.168.4.0 subnet and vice versa.

I can't google up anything on the Invalid transport field and can't figure out what to look for. Has anyone ever seen anything like this?

Thanks In Advance

 

[KiscoKid]

This is what the Error Message Decoder reports on the CCO for that error:

1. %PIX-4-500004: Invalid transport field for protocol=protocol, from source_address/source_port to dest_address/dest_port
This message appears when there is an invalid transport number, in which the source or destination port number for a protocol is zero. The protocol field is 6 for TCP and 17 for UDP.

Recommended Action: If these messages persist, contact the peer's administrator.

Related documents- No specific documents apply to this error message.


As you can see from your specific error, it seems the destination port is set to 0 which is invalid. Who looks after the source machine at 192.168.4.12? That needs looking at I think to understand why it's trying to connect to TCP port 0 on 192.168.1.222

 

[bubarooni]

The vendor maintains the machine. They were working with me trying to fix the problem but have pretty much thrown their hands in the air.

They are swearing to my boss that I've done something to the PIX that is blocking their machine. He in turn is telling me to 'fix it'.

Based on what you are saying is it safe to say that they are at fault and need to do something to their machine?

Thanks for the answer too! I have a meeting in 1 hour and 56 minutes were this is going to come up.

 

[KiscoKid]

I believe the fault is likely due to the device at 192.168.4.12 as it is initiating the TCP session and specifying a port number of 0 (which is invalid). A PIX can't modify a TCP port number from something non-zero to zero.

It may be that to prove your case that you need to put a network sniffer on the side of the PIX the host 192.168.4.12 resides upon (presumably the outside) and sniff packets coming from that host. It should be relatively straight forward to prove what destination port it is trying to connect to. You can download a free sniffer called Ethereal from

http://www.ethereal.com

 

[bubarooni]

Will do!

Thanks again.

 

[NetworkGhost]

For what its worth I also believe it is the IVR machine. Is that 25 opne for the machine or the machine needs access to port 25 on a remote device? Have you done a ping to the machine successfully from the Pix? Can ther machine successfully talk to any machine before the Pix? Maybe bad protocl stack on the IVR?

 

[bubarooni]

It was the IVR machine. They had set the protocol to zero instead of 25 for the mail that the IVR sends to my exchange server.

Unfortunately, it still doesn't work. Now they tell me it's because my IVR is blocked access to the internet, it has to check for messages on their POP3 server, by my firewall.

I have these lines in my outgoing access-list:

30 permit ip host 192.168.4.12 host xx.xx.xx.xx log (15525 matches)
40 permit ip host 192.168.4.12 host yy.yy.yy.yy log
50 permit ip host 192.168.4.12 any log (430 matches)

where 192.168.4.12 is the inside IP of the IVR machine and the x's are the ip of the POP3 server.

the above is partial results of a 'show access-list'. doesn't that first line mean that the IVR has total access to their mail server and and with over 15000 matches show that the IVR is getting to that machine?

 

[KiscoKid]

The access-list above is actually allowing full access for the inside host 192.168.4.12 to any outside destination.

Whilst line 30 will be looked at and matched against first, line 50 is a catch all which makes the other lines related to 192.168.4.12 pretty much redundant.

In short, 192.168.4.12 has unrestricted access to the outside network.

If you fire off the connection again and you start seeing matches on the ACL (you may also see entries on your log file), then I think you're in the clear.

 

[bubarooni]

Thanks KiscoKid, I was thinking so too. The redundant lines are really more for verification that I'm getting something to them than for any particular functionality. I'm getting a little desperate on this issue.

If the IVR does make contact with the POP3 server and pulls back mail, should I see PORT 110 traffic on the incoming access-list or can the IVR pull it back on a different port?

I added these lines to the incoming access-list just to check but they never show any matches:

 20 permit tcp host xx.xx.xx.xx any eq smtp log
 30 permit tcp host xx.xx.xx.xx any eq pop3 log
 40 permit tcp host yy.yy.yy.yy any eq smtp log
 50 permit tcp host yy.yy.yy.yy any eq pop3 log

I'm thinking that should give those two mail servers the right to send mail to anyone on the inside of my network, and am assuming that the nat will pass it back to the IVR.

It seems to me, their machine is refusing connections from the IVR or something.

I'd sure like to resolve this. My bosses are kicking me in the butt about every other day on this because they are being told by the vendor that the problem is me and my router.

one other thing, can i replace the the ip address of their mail servers with the fqdn? i.e. mail.somedomain.com instead of xx.xx.xx.xx

 

[KiscoKid]

Return path traffic from the POP3 server will come back with a source port of TCP 110 but a random destination port (i.e. greater than 1023).

Your ACL doesn't seen this as it's trying to match against a destination port of TCP 110. If you were to change it to match against a source port of 110, you may well see something.

If you need to categorically show you are now the cause of lack of communication between the 2 servers, you can either run a focused debug packet capture on the PIX to show what's happening with POP3 comms through the PIX. Or you could deploy a simple probe just to sniff the traffic on either side of the PIX to prove the flow of communications.

Regarding your last question regarding substituing an FQDN for an IP address, don't think you can do this but then again I've never tried. Other posters might think differently so I'd go with them regarding that.

 

[NetworkGhost]

You can capture the traffic by doing the following. If you see bidirectional traffic flowing the problem is most likely not with you.

access-list 150 permit ip host 192.168.4.12 host mailserver
access-list 150 permit ip host mailserver host 192.168.4.12

capture captraff access-list 150 buffer 8000 interface inside circular-buffer

Let the traffic start flowing then do:

sh capture captraff detail


You should see the traffic flowing both ways. You can change the interface you put the capture on. When you are done with the capture do:

no capture captraff
no access-list 150

 

[bubarooni]

Oh! I like that one. Will try and see what happens. Thanks!