Premature VPN Connection Failure with NIS 2010 on XP Pro PPTP VPN Server

Norton Security | Norton Internet Security
1

Firstly please accept my apologies if the following post is too long or breaks other conventions. It is my first time I've posted on this forum! Happy to receive advice in that context.

 

The issue I’d like to discuss involves the use of NIS 2010 deployed on an XP Pro host where that host is configured (via Microsoft's XP Pro facilities) to act as a PPTP VPN server in accordance with IETF RFC2637 - Point-to-Point Tunneling Protocol (PPTP).  This discussion has nothing to do with how VPN clients may be affected by NIS 2010, though I’ll note that no special configuration of NIS 2010 appears to be necessary when using the Microsoft VPN client in XP or Vista with NIS 2010 installed on that host.

 

The purpose for this VPN arrangement is to enable selected individuals to access company networked resources while away from the office. These individuals should be able to do this by establishing a VPN across the Internet to the office XP VPN server. As you might expect, the office’s Internet router firewall is setup to forward incoming packets with destination TCP port 1723 to, and permit GRE protocol with, the fixed IP address of the VPN server host.

 

In my opinion the only configuration of NIS 2010 required to support the above arrangement on the VPN server should be the opening of TCP port 1723 for any incoming IP address (custom configuration with this rule inserted as the first rule) and confirmation that GRE protocol is permitted (default config). This configuration certainly allows the initial connection of the VPN, however as observed by others on this Forum the VPN connection terminates after a short time (~80 seconds) due to some action of NIS 2010.

 

Work-around solutions proposed by Norton and Forum members include:

-          Change of NIS 2010 ‘Network Trust’ to include full trust of each apparent IP address of all VPN clients

-          Disabling of NIS 2010 Firewall ‘Stealth Blocked Ports’

 

Neither of these work-around solutions is attractive. Establishing Network Trusts with every VPN client, recommended to me by the Norton technician who investigated the issue I raised via NIS 2010 web help, is cumbersome and unworkable when individuals are travelling and using an ISP with dynamic allocation of an IP address (i.e. their VPN client’s IP address) for a matter of hours before moving to a new location/ISP and IP address. The custom configuration of the NIS 2010 firewall rule to allow VPN connections should be used by the firewall administrator to select either specific or ‘any’ incoming IP addresses as required, and in our case 'any' incoming IP address is the requirement. Disabling Stealth Blocked Ports cannot be healthy – it exposes a host to many threats even when they are restricted to the local office network.

 

Being a bit of an enthusiast and liking a challenge, I decided to use a Network Monitor together with IETF RFC2637 to determine why the connection was failing when NIS 2010 was configured the way I believed it should be. There is a simple answer to why the connection fails (incoming keep-alive packets on TCP port 1723 are denied by NIS 2010 contrary to its firewall rules – for more detail see below), and while this knowledge does not reveal to me any other more useful work-around, I hope that Norton might use this information (if it has not already established this level of detail for itself) to fix the underlying NIS 2010 problem.

 

I used Microsoft’s Network Monitor to record network traffic at both VPN client and server with and without the VPN server’s NIS 2010 firewall being active (logs can be provided on request). It appears that when the NIS 2010 firewall is active it denies incoming PPTP keep-alive packets (PPTP echo request and response) on the already established incoming TCP #1723 connection from the VPN client’s IP address. None of the firewall’s deny actions appear to result in events in the NIS 2010 user event log.

 

The TCP connection to the VPN server’s port 1723 is used for PPTP link management while VPN data between client and server is exchanged using GRE protocol (nothing to do with TCP). The first such PPTP TCP keep-alive packet is transmitted 60 seconds after the original TCP connection is established, per the RFC, but is denied by NIS 2010. Allowing ~20 seconds for TCP retries and VPN failure handling after the initial firewall ‘deny’ action explains why the VPN appears to fail ~80 seconds after VPN establishment when the NIS 2010 firewall is active. The NIS 2010 firewall’s deny action for an already-established incoming connection to TCP port 1723 from the VPN client’s IP address is contrary to the custom configuration of the firewall rules.

 

The action of the firewall to allow the initial PPTP connection on TCP port 1723 but then deny the PPTP keep-alive packets on the same port, coupled with the VPN work-arounds, suggests that the trusts/stealth blocking are taking precedence over custom firewall rules, not for the initial TCP connection but for subsequent traffic across the already-established TCP connection. Perhaps there is a timeout in operation and the pause of ~60 seconds in TCP traffic between establishing the connection and the first keep-alive handshake causes the NIS 2010 firewall to ‘forget’ there is an already-established connection on TCP port 1723?

 

If anyone has read this far I congratulate them! Here endeth my lesson! I'd be delighted if Norton acknowledes this is an issue and advises what remedial action is planned.

2

Hi delphinium

 

Congratulations, you read my novel! Flattery gets you everywhere, so I'm delighted to reply to your query. If I've misinterpretted your query don't hesitate to point this out.

 

The PPTP RFC places no requirement on synchronisation of client/server host clocks and hence system time does not feature in the PPTP protocol, though relative time does in terms of the scheduling of the TCP connection's keep-alive packets.

 

The XP Pro VPN server and client seem to consistently attempt the keep-alive handshake precisely 60s after the initial TCP port 1723 connection, so Microsoft seem to have correctly implemented the protocol according to the RFC.

 

In addition, the VPN connection works perfectly between the same hosts when NIS 2010 Firewall is disabled, so though your idea is a good one, and I know it can be an issue in certain types of authentication, I don't think it has any influence in this case.

 

Thanks for your interest.

3

Firstly please accept my apologies if the following post is too long or breaks other conventions. It is my first time I've posted on this forum! Happy to receive advice in that context.

 

The issue I’d like to discuss involves the use of NIS 2010 deployed on an XP Pro host where that host is configured (via Microsoft's XP Pro facilities) to act as a PPTP VPN server in accordance with IETF RFC2637 - Point-to-Point Tunneling Protocol (PPTP).  This discussion has nothing to do with how VPN clients may be affected by NIS 2010, though I’ll note that no special configuration of NIS 2010 appears to be necessary when using the Microsoft VPN client in XP or Vista with NIS 2010 installed on that host.

 

The purpose for this VPN arrangement is to enable selected individuals to access company networked resources while away from the office. These individuals should be able to do this by establishing a VPN across the Internet to the office XP VPN server. As you might expect, the office’s Internet router firewall is setup to forward incoming packets with destination TCP port 1723 to, and permit GRE protocol with, the fixed IP address of the VPN server host.

 

In my opinion the only configuration of NIS 2010 required to support the above arrangement on the VPN server should be the opening of TCP port 1723 for any incoming IP address (custom configuration with this rule inserted as the first rule) and confirmation that GRE protocol is permitted (default config). This configuration certainly allows the initial connection of the VPN, however as observed by others on this Forum the VPN connection terminates after a short time (~80 seconds) due to some action of NIS 2010.

 

Work-around solutions proposed by Norton and Forum members include:

-          Change of NIS 2010 ‘Network Trust’ to include full trust of each apparent IP address of all VPN clients

-          Disabling of NIS 2010 Firewall ‘Stealth Blocked Ports’

 

Neither of these work-around solutions is attractive. Establishing Network Trusts with every VPN client, recommended to me by the Norton technician who investigated the issue I raised via NIS 2010 web help, is cumbersome and unworkable when individuals are travelling and using an ISP with dynamic allocation of an IP address (i.e. their VPN client’s IP address) for a matter of hours before moving to a new location/ISP and IP address. The custom configuration of the NIS 2010 firewall rule to allow VPN connections should be used by the firewall administrator to select either specific or ‘any’ incoming IP addresses as required, and in our case 'any' incoming IP address is the requirement. Disabling Stealth Blocked Ports cannot be healthy – it exposes a host to many threats even when they are restricted to the local office network.

 

Being a bit of an enthusiast and liking a challenge, I decided to use a Network Monitor together with IETF RFC2637 to determine why the connection was failing when NIS 2010 was configured the way I believed it should be. There is a simple answer to why the connection fails (incoming keep-alive packets on TCP port 1723 are denied by NIS 2010 contrary to its firewall rules – for more detail see below), and while this knowledge does not reveal to me any other more useful work-around, I hope that Norton might use this information (if it has not already established this level of detail for itself) to fix the underlying NIS 2010 problem.

 

I used Microsoft’s Network Monitor to record network traffic at both VPN client and server with and without the VPN server’s NIS 2010 firewall being active (logs can be provided on request). It appears that when the NIS 2010 firewall is active it denies incoming PPTP keep-alive packets (PPTP echo request and response) on the already established incoming TCP #1723 connection from the VPN client’s IP address. None of the firewall’s deny actions appear to result in events in the NIS 2010 user event log.

 

The TCP connection to the VPN server’s port 1723 is used for PPTP link management while VPN data between client and server is exchanged using GRE protocol (nothing to do with TCP). The first such PPTP TCP keep-alive packet is transmitted 60 seconds after the original TCP connection is established, per the RFC, but is denied by NIS 2010. Allowing ~20 seconds for TCP retries and VPN failure handling after the initial firewall ‘deny’ action explains why the VPN appears to fail ~80 seconds after VPN establishment when the NIS 2010 firewall is active. The NIS 2010 firewall’s deny action for an already-established incoming connection to TCP port 1723 from the VPN client’s IP address is contrary to the custom configuration of the firewall rules.

 

The action of the firewall to allow the initial PPTP connection on TCP port 1723 but then deny the PPTP keep-alive packets on the same port, coupled with the VPN work-arounds, suggests that the trusts/stealth blocking are taking precedence over custom firewall rules, not for the initial TCP connection but for subsequent traffic across the already-established TCP connection. Perhaps there is a timeout in operation and the pause of ~60 seconds in TCP traffic between establishing the connection and the first keep-alive handshake causes the NIS 2010 firewall to ‘forget’ there is an already-established connection on TCP port 1723?

 

If anyone has read this far I congratulate them! Here endeth my lesson! I'd be delighted if Norton acknowledes this is an issue and advises what remedial action is planned.

4

Andrew_99,

 

Thanks for the thorough analysis and taking the time to document your experience. The XP VPN is tested with every release of the products so I expect that there is some other variable that is changing the NIS behavior in your case. I will pass this information to my team to see if they can reproduce your issue.

 

When you mention the firewall 'deny' action, is this referring to some sort of log entry? If it's a log entry, the full text would help to understand which portion of the code is generating the action incorrectly.

 

Based upon your description, what I suspect is happening is that NIS sees the incoming SYN and allows it due to the rule that you've created for port 1723. It probably also sees the following SYN-ACK that is sent in reply. It may even see the final ACK that established the connection. After that, though, all packets on that connection get routed to the VPN stack first, rather than the TCPIP stack, and since NIS is unaware of any connections on that stack it thinks that they are targeted to a non-active circuit/connection. Why the behavior on your machine is different from our standard testing is unknown but as I said, we'll investigate it.

5

Hi Reese

 

Thanks for your quick response. I’m delighted I’ve found a technical communication channel with Norton!

The experience I’ve documented with NIS 2010 has been my experience with several previous releases of NIS, e.g. NIS 2009, and I suspect from browsing the Forum I’m by no means alone in experiencing this behaviour.

 

Some of key features of our setup required to replicate this behaviour are:

 

-          NIS 2010 is installed on the XP Pro PPTP VPN server. I see the majority of Forum posts re VPN issues  are related to VPN clients, but the Network Monitor trace reveals that in the setup I’m describing the MS VPN server host’s behaviour is at fault while the MS VPN client host’s  behaviour is strictly in accordance with the RFC and therefore has no relevance to the issue I’m reporting, albeit in our case it also has NIS 2010 installed;

 

-          The incoming VPN connection must be from a client IP address that does not form part of an NIS 2010 Network Trust. While I can see some businesses would want to restrict incoming VPN connections to a set of known, fixed and trusted IP addresses, this is most definitely not the case for us for the reasons described in my original post, hence the NIS 2010 PPTP firewall pinhole is custom configured for any incoming IP address. I believe this to be a legitimate use of the intended VPN functionality as described in the RFC;

 

-          The VPN server host’s NIS 2010 custom configuration should be restricted to the firewall pinhole I described in my original post.

 

If your team can replicate the above I feel sure they will encounter the same VPN premature disconnection issue as I described in my original post, and they will find that when the NIS 2010 firewall is disabled the premature disconnection issue disappears.

 

Unfortunately the ‘deny’ action I describe is not logged in any of the NIS 2010 logs available to me, and this suggests that the firewall may be denying the keep-alive packet in some unexpected way. Perhaps I am unaware of ways of increasing the level of firewall logging which would reveal the deny event? Perhaps also my use of the word ‘deny’ has inappropriate connotations in a firewall context? I guess I'm trying to say that the TCP packet doesn't make it through the firewall, whether intentionally or otherwise.

 

I concluded that an NIS 2010 firewall deny action had taken place because I was able to run the MS Network Monitor 3.3 on both ends of the VPN (effectively accessing each host’s NIC?) and could see that in response to the VPN server’s PPTP keep-alive request the VPN client’s PPTP keep-alive reply, which reached the VPN server’s NIC, was not received by the VPN server’s TCPIP stack because the TCPIP stack treated it as a ‘lost’/un-received packet. Furthermore, when NIS 2010 firewall is disabled the VPN functions exactly per the RFC, leading me to conclude the ‘problem’ is within NIS 2010.

 

I am confused by your remark about packets being routed to the VPN stack first, rather than the TCPIP stack, after the VPN connection is established. My understanding from the RFC is that VPN link control is over the TCP/IP connection while VPN data uses GRE protocol over a separate connection which does not use TCP/IP. So, after the TCP/IP PPTP link control connection is made, I’d imagined that a GRE protocol link would be established independent of the TCPIP stack between VPN client and server, and that the TCPIP stack would continue to handle the TCP/IP communications used for PPTP connection management. Happy to be advised otherwise, I’m not an expert!

 

I would be delighted to send you my MS Network Monitor 3.3 traces if these would be of interest.

 

Might I fly a kite? Dangerous I know, but perhaps the in-house Norton testing assumes the VPN client IP address is always associated with a NIS 2010 Firewall Network Trust, and therefore our setup, which I feel is legitimate, has not been tested in-house before? Just guessing…

 

Please let me know if I can be of further assistance, and if the Network Monitor trace files would be of any use.

 

Best regards
Andrew

6

Andrew_99,

 

Thanks again for the additional details. If the team needs anything else, I'm sure that they'll be contacting you.

 

I'm certainly no expert on VPNs and your most recent message led me to do a little research. NIS has no logic for the GRE protocol other than to allow it or not (found under Network:Settings->Smart Firewall:Advanced Settings:Configure->Uncommon Protocols:Configure->Protocol number 47 enabled (or disabled). If this is enabled, which is the default, GRE traffic should go through unmolested.

 

Once the PPTP connection has been established (over TCP), the traffic goes back and forth without any modification and the only thing that should terminate that connection should be an IPS detection.

 

My previous speculation was probably incorrect but I think that it is still close. Conceptually, TCP traffic, when going over a VPN, enters the top of the TCP stack and goes all the way through the stack until it gets to the routing portions, at which point the internal router chooses to send the packet to the 'VPN device'. The VPN device encapsulates this packet and re-enters the top of the stack with new packet, which quick traverses the stack down to the router which figures out which adapter can access the VPN server's IP address and then transmits the encapsulated packet to that adapter. The stack or VPN implementation may not actually go through all that, though, and simply re-enter the routing layer. I suspect that the problem lies somewhere in this re-entrant handling. Since I don't actually know the behavior of the VPN or the stack in these circumstances I could be completely wrong though.

 

Regardless, the information that you've provided should be useful in reproducing this issue for us to look into.

7

Hi Reese

 

Thanks for your clarification about the operation of the VPN and TCPIP stack. I can now see where our perspectives have differed: we were referring to quite different TCP traffic and connections!

 

I believe you were describing application-related TCP connections and traffic that are routed across a VPN once it is established, i.e. using the VPN end-point IP addresses which are different to the VPN client’s and VPN server’s host IP addresses. I think you are absolutely correct in your functional description regarding how such connections are established and how related traffic flows across the VPN, at least that’s how I view it too. The GRE protocol is used to convey all traffic, TCP or otherwise, across the VPN.

 

I was referring to a totally different TCP connection, that between the originating VPN client host (TCP port <any>) and VPN server host (TCP port 1723), using the VPN host IP addresses. This TCP connection is essential for the VPN to be established, maintained and terminated between the hosts. This TCP connection knows nothing about the VPN’s endpoint IP addresses, nor does it support any VPN traffic, it is purely used for link control of the VPN connection, and in my experience once established it is practically silent except for the keep-alive packets every 60s and eventual VPN termination. It is PPTP keep-alive packets on this TCP link that are being ‘obstructed’ by the NIS 2010 firewall on the VPN server host, in particular when the first keep-alive related TCP packet is received at the VPN server some 60s after the TCP connection is first established, the packet is received by the host’s NIC, but never makes it as far as the host’s TCPIP stack, presumably because NIS 2010 obstructs it in some way.

 

Note that the first TCP PPTP-related keep-alive packet being received by the VPN server host can either be a keep-alive request or a keep-alive echo, depending on whether the VPN server or VPN client was first to raise a PPTP keep-alive request (either end of the VPN connection has the right of raising a PPTP keep-alive request after 60s of PPTP control link inactivity).

 

Anyway, thanks again for your help and I look forward to hearing from you and/or your team in due course.

 

Best regards
Andrew

8

Andrew_99:

 

I can see that you were holding back in your first post.  :smileyvery-happy::smileytongue:

9

Andrew_99, thanks once more for the additional information. It does make more sense to me now since I thought you were discussing the GRE keep-alive packets. This now matches closer to my first theory.

 

A PPTP connection is established. Using data provided in that connection, a GRE channel is established which essentially cause all new traffic to be transferred over the GRE 'adapter'. Unfortunately it's not 'all' traffic, because the PPTP traffic doesn't get tunnelled and probably any other pre-existing network connection traffic. It's probably these pre-existing connections on the non-tunneled stack that get lost when the tunnel is established causing this problem.

 

Somebody is already actively working on reproducing your scenario and hopefully they'll succeed soon.

10

Hi Reese

 

Thanks for your reply. See below my in-line comments [in red font] on your last post. Hopefully this is of some help..

 

A PPTP [TCP link control] connection is established. Using data provided in that connection, a GRE channel is established which essentially cause [creation of new VPN endpoint ‘adapter’ IP addresses and related changes in each VPN host’s IP routing table such that] all new traffic to be transferred over the GRE 'adapter'.

 

[I agree that this seems to match the observed behaviour, e.g. in XP and Vista it appears that all Internet traffic to/from the VPN client host starts being routed via the VPN server by default despite there being e.g. a perfectly good Internet connection via the VPN client host’s NIC. I guess this is as a result of the changes that occur to the IP routing table in the VPN client on establishment of the VPN. I think I have observed corporate VPN connections that do not follow this arrangement, but I suspect these involve sophisticated scripted changes to the VPN client’s IP routing table that do not occur at the simple ‘retail’ level provided by Microsoft as part of XP/Vista and used in our scenario.]

 

Unfortunately it's not 'all' traffic, because the [pre-existing] PPTP [link control] traffic doesn't get tunnelled [and must not get tunnelled, otherwise the PPTP VPN control link connection would not comply with the RFC, and the VPN would fail.] and probably any other pre-existing network connection traffic. [I'm not sure about this. Would other pre-existing TCP connection traffic, with the exception of the PPTP link control connection, perhaps be dynamically re-routed between its endpoints, if necessary, depending on the new versions of the VPN client and server IP routing tables post establishment of the VPN adaptor, i.e. IP routing changes, but TCP connections remain intact? I’m really not sure.] It's probably these pre-existing connections on the non-tunneled stack that get lost when the tunnel is established causing this problem. [You could very well be right, but the VPN itself should stay established as long as the PPTP TCP control link is properly maintained via the original client and server TCPIP stacks used for its original establishment. I can confirm that when the VPN is established with NIS 2010 firewall disabled at the VPN server host the TCP/IP connection for the PPTP control link appears to continue without interuption suggesting the original TCPIP stacks are intact.]

 

If you are able to re-create the scenario I described in your environment, I’m sure much of what I’m trying to communicate here will become obvious.

Thanks again for your prompt attention. Good luck!

Best regards
Andrew

11

Just an update, it looks like we may have reproduced your issue. The connection persists as long as network activity occurs but once the network has been idle for a while the connection drops. More research is continuing...

12

Hi Reese

 

Thanks for your update. I'm not convinced the issue I'm seeing is traffic-related, but you never know...

 

I re-ran my in-house VPN test today. The VPN Test Client shares the same office LAN as the VPN server. Traffic was forced continuously across the VPN immediately after it was established - the VPN happily passed the bidirectional traffic until the VPN unilaterally terminated 80 seconds after it was established. This failure is consistent, and occurs unless I have previously made one of the following changes to the VPN Server's NIS 2010 settings:

 

(1) disabled the firewall;

(2) disabled 'stealth blocked ports'

(3) increased the 'trust' level for the VPN client from 'shared' to 'full'.

 

With any of the above NIS 2010 configuration changes on the VPN server the VPN runs indefinitely, but then the VPN Server's security is compromised and/or it is not possible to predict all the IP addresses with which full trusts are required when VPN Clients connect across the internet from temporary locations.

 

To help clarify my setup I've drawn an architecture diagram in pdf. The diagram incudes specific client and server IP addresses which may help if you should ask for the network monitor capture files I hold. I have discovered that this file type cannot be attached via the forum's 'post' mechanism, but if you let me have your email address I would be delighted to send it to you - I really think it is a case of a picture saying 1000 words! In addition, I would be delighted to provide remote access to the hosts involved for your team to investigate this issue further.

 

Best regards

Andrew

13

Hi Andrew_99

 

Have been reading your post with some interest.  I just have one quick question though.  I take it your XP Pro PPTP Server opens this connection at the request of the client; but does it then pass the GRE payload traffic on to another machine or is the server the final destination?

 

I ask due to having a similar problem at one time.  We overcame this by doing server to server PPTP and getting away from MS completely for those servers.

 

Yet, as I remember - XP will automatically pass on (redirect) the GRE traffic when port 1723 (PPTP) is forwarded  to another host (server) if ICS is enabled as stated by MS.  You might look to see if NIS is hindering that pass.  That is, IF I remember correctly!

 

This may be all completely irrelevant; somewhat do to my inability to see your network layout - I am making some rather broad assumptions.

 

Good luck with your situation - excellent post by the way, quite informative and well described.  I'll keep track.

14

Hi MikeSp

 

Thanks for your interest and suggestions. It is a shame my network architecture diagram is unavailable as part of the post thread, but I did manage to email it to Reese so hopefully Reese and the support team now have a clearer view of my setup – it is nothing special to be honest.

 

The port forwarding we’ve setup for incoming PPTP traffic is in our office’s Internet Gateway NAT router, a ‘2Wire’ device supplied by our ISP and loaded with ISP-specific software. We do not have Microsoft ICS enabled on any of our hosts, though it sounds like ICS does the same job as a router and therefore has similar user-configurable functions like port forwarding. The forwarding rule in our router points all incoming PPTP-related traffic (TCP 1723 and GRE) to our fixed (private) IP address VPN server located on the XP Pro host that I’ve described in earlier posts.

 

One can toggle the success or failure of this VPN handling arrangement by simply altering the configuration of NIS 2010 on the VPN server host as described in my last post (see the 3 changes that result in the VPN working indefinitely). The key point here is that it appears to me the VPN Server NIS 2010 configuration that should support the VPN indefinitely is the one that results in its premature failure, and the work-around solutions all result in increased vulnerability and/or unworkable administration. The problem definitely lies in our NIS 2010, whether as the result of NIS 2010 software functionality, or my mal-configuration of it.

 

You query the routing behaviour over the VPN? When the VPN is established the VPN client finds it has a new network ‘adapter’ (see Reese’s earlier post) allocated with an IP address belonging to the private network to which the VPN server is connected (at least that’s our arrangement which was defined in the VPN Server’s setup, though I suspect more experienced administrators could perhaps elect for something different). What the netmask, default gateway and other related settings are for the new adapter is not clear to me (I haven’t looked), but once the VPN is established Internet traffic to/from the VPN client appears to traverse the VPN and access the Internet via the VPN Server and Office Internet gateway router in preference to using the (more direct?) route of the VPN Client host’s NIC and local Internet Gateway as it would have done prior to the VPN being established.  I assume the VPN client and VPN server routing tables are updated automatically on establishment of the VPN, and this is perhaps what determines the route the traffic takes.

 

Thanks again for your interest.

15

Andrew_99,

 

Thank you for your help with this. After some analysis, we have determined that the Microsoft VPN Server is doing some 'illegal' things -- primarily, it's not completing the PPTP connection using the normal TDI interfaces and, instead, is calling directly into the stack bypassing any filters (such as firewalls). Symantec is not likely to have a hack for this issue any time in the foreseeable future, if at all. The end user workaround for this problem is to disable stealthing, the value of which can be debated separately.

 

Although the Symantec firewall code is the same for Vista, it appears that Microsoft may have already fixed this problem in that operating system. The Symantec and Microsoft firewall code on Win7 is completely different from the previous OS releases. This means that the problem only affects Windows XP users.

16

Reese

 

Thanks for investigating this issue in some depth.

 

Given the legacy nature of XP and changes in Windows Vista and 7 implementation of the VPN server by Microsoft, I appreciate that it is unlikely any further action will be taken to develop a 'hack' in NIS firewall specifically for XP. We will actively consider use of the stealth-blocked-ports workaround, perhaps with additional external-to-NIS security measures, for our setup until we upgrade the VPN server host to a later edition of Windows.

 

I'm very happy to class your last communication as a 'solution' to the problem.

 

Best regards, Andrew