Monitoring packets on the WAN side of the firewall

The Cisco SG300 switch came Saturday. I set Lamb’s Ethernet interface to the non-routable sub-net which contains the SG300s default IP address (192.168.1.x), and logged in to the switch. I picked a strong password and configured it, including setting it up to mirror all the traffic to and from the port where I planned to install AT&T’s router to the port where Lamb – my intended monitoring computer — was currently plugged in.

Then the lights went out. Well, figuratively, at least. Lamb could no longer communicate with the SG300 management GUI. I did some reading on the web. It turns out that this behavior is normal. What’s going on? When you tell a SG300 switch to mirror traffic to a particular port, that port becomes dedicated to that purpose, and won’t do anything else. So, telling the switch to mirror to the port I was using for management made that port useless for management, and all I got was browser timeouts.

I was planning on changing the IP address of the management interface to the switch to one on the subnet that the router and the WAN port of the firewall were using, but it occurred to me that that was not only unnecessary, it was unsafe. Having the management GUI of the SG300 on an un-routable subnet meant that there was no way that anybody on the Internet could send packets to the management interface! I guess I didn’t need that strong password after all.

Now that I finally understand how Cisco does port mirroring, it turns out that I wasted all that time configuring Lamb to sit on the outside of the firewall. When Lamb is hooked up to the port that the switch is using to mirror all the router packets, it can’t receive any other traffic, and is therefore invisible to any Internet-connected device. I left Lamb’s Ethernet IP address as non-routable just to make sure.

I connected the SG300 between the firewall and the router, and connected Lamb to the monitoring port. I fired up Wireshark, and told it to start collecting packets. I went upstairs and tried to make an outgoing SIP phone call. It failed, just as before. I stopped collecting packets. I told Wireshark to just show me the SIP packets. As before, there were four. An “Invite” packet from the PBX to AT&T’s SIP server. A “Trying” packet from the SIP server to the PBX, immediately followed by a “Forbidden” packet. The last packet was an “Ack” from the PBX to the SIP server.

I looked at the contents of the packets. They looked like the packets I had been seeing before using the Sonicwall Dashboard packet monitoring feature.

My take on things is that one or more of three things is wrong with the “Invite” packet:

• It’s from the wrong IP address.
• It’s to the wrong IP address.
• There’s something in the packet body that’s not right.

Any of these three things could be caused by misconfiguration of the PBX or of the SIP server. I’ll see if I can get the AT&T techs to look at the Wireshark log and tell me what they think.

By the way, here’s a useful link on the various ways to connect a computer for packet monitoring.