Connectivity Issues w/ Symantec Endpoint Protection on host

[Dewin]

We recently swapped to using Symantec Endpoint Protection after a recent evaluation period, during which there were no problems. This particular host was actually the first test subject, as it's my development machine and I'm the system admin who pushed for the deployment.

Everything was working fine for me last week, but as of today I'm experiencing this absolutely bizarre issue:

Host: Windows 7 Professional x64. Virtualbox 4-2-14 and 4-2-16 (tested with both versions)
Host Antivirus/Firewall/Etc: Symantec Endpoint Protection 12-1 (SEP)
Guest: Debian Linux 6-0-6 amd64 (squeeze/stable)
Guest Antivirus/Firewall/Etc: None, and no iptables rules either.
Network Configuration: Guest has 3 interfaces: #1 is bridged to the host's Ethernet interface (192-x), #2 is a host-only network (172-x) and #3 is NAT.

I'm unable to SSH from the host to the guest on any interface, but H-T-T-P traffic (why do these forums think this abbreviation by itself is a link?) on port 8888 from the host to the guest works fine. I can SSH from the host to another PC and then from there to the guest just fine, and outbound connections from the guest work just fine.

There is no firewall rule in SEP that would be blocking this level of SSH -- in fact, disabling all firewall rules does not solve the problem, nor does creating a "catch all" rule that allows all traffic as the first rule. Completely disabling the firewall (aka "Network Threat Protection", to use Symantec terminology) resolves the problem (but this is not a satisfactory fix.) Furthermore, this was working last week with all of this enabled.

A catch-all "block all remaining traffic and log it" rule fails to log anything relevant, either.

Any idea what might be going on here and what else to consider? I'm running out of ideas.

[Perryg]

VirtualBox provides the adapter hook but beyond that it really has little to nothing to do with the network. You say it worked last week. What could have changed between then and now? It might be worth running something like wireshark and see where the port is failing.

Oh and ssh'ing to the guest over NAT would mean you have forwarded a port. Are you sure that it is not in conflict? Normally most people use host-only with NAT which would not cause an issue since you would use the host-only to ssh with, or forward if you need to NAT. Adding the bridge just might cause a conflict.

It is preferred in most cases to use Bridged when ever possible since it resembles a PC on the LAN

[Dewin]

Nothing's changed since last week, which is what baffles me. What really gets me is that it works with the host's firewall disabled, but not with the firewall enabled with no rules to block anything. Oh, and only the host is unable to connect to the guest, other machines on the network can access it just fine (to the point where I can ssh out to another machine and then right back into the guest)

As a clarification, the guest has 3 interfaces: one bridged, one host-only, one NAT. The odd interface setup is due to the fact that the host is a laptop and the bridging is the normal desired behavior, but the host-only method allows me to still connect from the host to the guest even when I'm disconnected from the network (i.e., using the laptop as an actual laptop), and the NAT interface is so the guest can still access the internet in that same situation.

[noteirak]

Well the issue clearly lies with Symantec here... Maybe there was an update of Symantec itself?

On the note that it only doesn't work from the host, maybe that needs to be explicitly allowed or something?

[Perryg]

Very well. As I said above though VBox simple provides the mechanism (hook) to the hosts adapter. If disabling SEP resolves the issue then it must need a rule filter to allow this to work. I would contact them to see what needs to be addressed. Usually it is as simple as allowing a certain address or subnet, but I don't use SEP or equivalent so I could not direct you to the exact location or cure.

[Dewin]

As a fun update, it turns out that ssh sometimes begins to work, to the point where I can login and /var/log/auth.log reports the login session opening -- but my SSH client never reaches a login prompt. Hmm.

Come to think of it, I used to occasionally get "Incoming packet was garbled upon decryption" from PuTTY/SSH even before we had SEP, so I almost wonder if something more complicated is at play here.