Endpoint Protection Small Business Edition

SEP Version 12.1.1000.157 RU1

We currently have clients connecting through Direct Access which is IPv6. It seems our version of SEP does not support connections from the SEP clients using IPv6 to SEPM. This is causing our client virus defs to become out of date. Is there an update or a newer version of SEP which supports IPv6 connections.

Thank you,

Sincerly

Jason

HI,

Check this

IPv6 support in Symantec Endpoint Protection 12.1

http://www.symantec.com/business/support/index?page=content&id=TECH174897

Check this also

Check in SEPM firewall

Microsoft DirectAccess:
To allow Microsoft DirectAccess to work, you will need to:

1. Enable the Windows Firewall (for Windows 7, it should already show as enabled and managed by SEP).
2. Change the SEP firewall rules for IPv6 traffic to from "Block" to "Allow".
   • Please note the IPv6 support information below

Check this artical

http://www.symantec.com/business/support/index?page=content&id=TECH134869

Check this thread

https://www-secure.symantec.com/connect/forums/sep-directaccess-windows-8

Hello,

What OS is running on your client machines?

Check these Articles:

Support of Microsoft DirectAccess and IPv6 (in Windows 7)

http://www.symantec.com/business/support/index?page=content&id=TECH134869

How to configure Symantec Endpoint Protection 12.1 for use with Microsoft's DirectAccess

http://www.symantec.com/business/support/index?page=content&id=HOWTO55829

Thank you for the quick replys.

The issue we are facing is that the Apache which comes with SEP 12.1 RU1 does not listen on IPv6. Since our Direct Access clients are stricktly using IPv6 over ISATAP they can not connect to SEPM (Apache) and get there virus deffinitions. Our issue is not a firewall or a Direct Access issue.

Are the Apache versions included in newer releases such as 12.1 RU1 MP1 or 12.1 RU2 compiled with IPv6 support?

We are currently on 12.1 RU1.

Thanks

Jason

#EDIT#

Hello,

SEPM 12.1 RU2 Apache is not compiled with IPv6 support.

Hi Jason,

As you have already discovered, the primary issue is that the Apache server does not have IPv6 support.
It's ironic that the client is actually capible of requesting policies via IPv6 (Because it uses WinHTTP, a Microsoft library that support IPv6), but the server is not capibile of serving the policies via IPv6. You can verify this by running "Netstat -anop tcpv6"

I have found one work around, that is in no way 'supported', is to use some sort of IPv6 to IPv4 translator.

I'm sure these products are becoming more and more common, for my testing, I used a simple web proxy that is able to listen on the IPv6 stack. Then I told the proxy to forward all web requests to Apache's IPv4 port.

So a quick diagram would look like this:

SEP Client --> IPv6 Web Proxy --> IPv4 SEPM Server

What's nice about this setup is you don't have to 'tweek' configuration files. All you need is:

1) Install a Web Proxy that has IPv6 cabability, you can find these for free on the internet.
2) Configure the Web Proxy to forward traffic to SEPM.
3) Update SEPMs "Mangement Server List" policy to have the IPv6 address of the Web Proxy. (I recommend keeping the IPv4 address as a P2/P3 for backup)

I have tested this, but not extensively. Other than the fact that the Troubleshooting --> Connection Status panel on the client not working when using IPv6, and some strange error in the Sylink.log file, there seemed to be no functional issue. Policies etc did download and apply.

So I can't guarentee it will work seemlessly, but I think it's worth a try. You can even install the IPv6 web proxy on the same server as SEPM.

I don't think it was.

Thank you for the replies from everyone. Excellent response Ghent!

On another note. You can also change to the apache\bin folder and run httpd.exe -V at a command prompt to see how Apache was compiled. If Apache is compiled with IPv6 you should see the following compiler flag.

  -D APR_HAVE_IPV6

Thanks

Jason

Hello,

I appreciate you for the above comment and clear explaination.

I completely agree with you.

Ghent,

Researching into your solution further, it looks like Windows has a v6tov4 proxy built right in called portproxy. It does not look like a 3rd party proxy software would be needed.

The command is something like: netsh int portproxy

Cool stuff.

Thanks

Jason

Interesting. Never heard of this, but it looks like it would do the trick.

Here is an important thing to remember when forwarding traffic to SEPM.

Do not use "localhost" or "127.0.0.1" address. If forwarding traffic within the local system, I also avoid using the hostname because sometimes this is translated as the localhost address 127.0.0.1

This is because the Secars.dll has a security check to NOT allow clients to communicate via the localhost address. Only Tomcat is allowed to talk to Secars.dll using the localhost address. All client traffic must have an external IP address in their IP packet when it hits Apache.

I've never seen heard of ProxyPort, but it looks like a very useful tool to me. I would guess a command like this would do the trick: netsh interface portproxy add v6tov4 listenport=80 connectaddress=192.168.0.1 connectport=8014 listenaddress=::0 protocol=TCP

Not so sure about the IPv6 address format. (Again, "connectaddress" cannot resolve to 127.0.0.1)

I can verify that using portproxy works!

In an elevated command prompt on the SEPM server you issue a command such as:

netsh int portproxy add v6tov4 listenaddress=<IPv6 address> listenport=8014 connectaddress=<IPv4 address>

In our case the IPv6 is the 2002: address of the ISATAP adapter on the SEPM server. The IPv4 is the static IP of the SEPM server.

You can see your mapping with: netsh int portproxy show all
To remove all mapping you can simply use: netsh int portproxy reset
Note: The portproxy mappings remain in effect after rebooting.

We also have found out you have to create a inbound firewall rule on the SEPM server (in the Windows firewall) allowing TCP port 8014. After doing these steps the SEP client connects on a IPv6 computer. We are still testing but have not seen any issues.

A good way to test if everything is working. Bring up IE on the SEPM server or the DA client and enter:
http://[IPv6_address_of_SEPM]:8014/content/contentinfo.txt

You may also want to look in the logs of the SEP client and see what it is trying to connect to. The client will need to resolve the DNS name of the SEPM server to a IPv6 address. With UAG we did not need to do anything special or change any settings for this to happen. DNS64 took care of it.

UAG Direct Access has built in NAT64 support which may work for some and they will not need a work around. We have a firewall between the UAG and our internal network causing our issue.

Sincerely,
Jason
 

Thank you for letting us know the results. This is very intersting to me.