Mark Pimentel wrote:
>Still doesn't seem to do anything. I dont even get
>any logging either. Any thoughts?
I had to work on this awhile back myself and was able to get it to work by:
(1) Setting up DHCP to hand my work laptop an address based on MAC
address (so I always got the same IP)
(2) NATing UDPs on port 500 only back to my laptop's IP address
(3) Allowing fragmented packets
This would appear to "fail" the first couple of times I tried to log
into No-Tell VPN back into work, then on the third attempt, it would
magically work. I continued and improved to success on every connection
(1) Removing the NATing rule
(2) Continuing to allow fragmented packets
(3) Continuing to obtain IP address via DHCP mapped by MAC to my laptop
(4) Setting a WAN rule to port forward all packets on any port from the
lower 15 IPs coming from my work place back to my laptop IP
I wasn't aware of traffic on port 10001; I never saw that in my logs and
by restricting port forwarding to my company's public VPN IP addresses,
I've limited where incoming SYN packets will be received in this
scenariio. This works fine for me. I find the Nortel VPN connectiivty
solution pretty chinsey compared to other VPNs I have used.
I can provide you with screen prints of my WAN ruleset if this helps.
It was a bit of a pain to get this to work. The real problem, in my
opinion is accouting for the SYN packet(s) back and thus the port
forwarding was my solution. Perhaps a better one exists, but from what
I saw in the logs as I was trouble-shooting this, I didn't see any way
around it. Now knowing about port 10001, I might look into something a
little more restrictive, but I feel pretty good with the restricted IPs
being forwarded back at this point.
I'm surprised you don't get logging. You may want to look into your
overall logging setup; that is what helped me solve my problem -- seeing
the SYN from port 500 trying to get through.
chris at technologEase dot com