How to configure rules for NetExteneder Client behind TMG 2010 FW
Hi all,
I have the following Situation:
I am running a Windows 8 Maschine with Sonic Wall Netextender on it (customer request ;-/). MY Network is secured thru TMG 2010. When I am inside my LAN I am not oble to connect to my customers Sonicwall with Netextender Client.
I have created a FW rule allowing TCP IP from internal to the specified IP, beside this I have created a Network rule from my internal Network to the customers Firewall IP (route).
When I try the Connection TMG tells me that
"A connection was closed because no SYN/ACK reply was received from the Server"
What is my fault ?
Thanks in advance !
Martin
I have the following Situation:
I am running a Windows 8 Maschine with Sonic Wall Netextender on it (customer request ;-/). MY Network is secured thru TMG 2010. When I am inside my LAN I am not oble to connect to my customers Sonicwall with Netextender Client.
I have created a FW rule allowing TCP IP from internal to the specified IP, beside this I have created a Network rule from my internal Network to the customers Firewall IP (route).
When I try the Connection TMG tells me that
"A connection was closed because no SYN/ACK reply was received from the Server"
What is my fault ?
Thanks in advance !
Martin
ASKER
Bernbi,
tried, unfortunatly this does not solve the issue.
Errormessage:
A packet was dropped because its destination IP address is unreachable
I am quite sure I use the correct IP :-)
Any other idea ?
Regards
Martin
tried, unfortunatly this does not solve the issue.
Errormessage:
A packet was dropped because its destination IP address is unreachable
I am quite sure I use the correct IP :-)
Any other idea ?
Regards
Martin
Sorry, I guess this was the other side.
Nevertheless as stated in the article, it uses SSL Port 443 on the other side.
If you client tries to connect to this target, the Web Proxy Filter is touched and this is not a good idea. So you should go around the web proxy filter.
The error message (no SYN/ACK) means, that something is send out, but nothing comes back, at least not for the original package. If you set a routing network relation to this (public) target, your client IP is send with the package, and as it is a private IP, it expalins, why nothing comes back.
You may try the following.
Create a new protocol definition for HTTPS. Port 443 Outbound (no filters)
Create two network computer objects, one for your client, anotehrone for the customer Sonic Wall.
Create a new rule, add your user defined HTTPS protocol, from your client to the Sonic wall (use the computer objects) and move it before any other rule, which contains HTTP / HTTPS.
Leave out the network rule.
Nevertheless as stated in the article, it uses SSL Port 443 on the other side.
If you client tries to connect to this target, the Web Proxy Filter is touched and this is not a good idea. So you should go around the web proxy filter.
The error message (no SYN/ACK) means, that something is send out, but nothing comes back, at least not for the original package. If you set a routing network relation to this (public) target, your client IP is send with the package, and as it is a private IP, it expalins, why nothing comes back.
You may try the following.
Create a new protocol definition for HTTPS. Port 443 Outbound (no filters)
Create two network computer objects, one for your client, anotehrone for the customer Sonic Wall.
Create a new rule, add your user defined HTTPS protocol, from your client to the Sonic wall (use the computer objects) and move it before any other rule, which contains HTTP / HTTPS.
Leave out the network rule.
ASKER
Bernbi,
done...
created the computer objects for both the internal computer that is using the Netextender Client and one for the Sonicwall at the site if my customer.
created the https protocol definition
created a new rule that uses internal computer as "from", sonicwall-computer-object as "to" and https protocoll as protocol.
turned on the NAT relation between internal network and target IP
.... still telling me...
A packet was dropped because its destination IP address is unreachable
;-(
Any other idea ? It is SO frustrating ....
Thanks for your support so far !!
Regards
Martin
done...
created the computer objects for both the internal computer that is using the Netextender Client and one for the Sonicwall at the site if my customer.
created the https protocol definition
created a new rule that uses internal computer as "from", sonicwall-computer-object as "to" and https protocoll as protocol.
turned on the NAT relation between internal network and target IP
.... still telling me...
A packet was dropped because its destination IP address is unreachable
;-(
Any other idea ? It is SO frustrating ....
Thanks for your support so far !!
Regards
Martin
The destination IP should be the IP of the sonicwall. So, first at all, you should be able to ping the target from TMG, if the sonicwall responds to a ping. I'm not sure if the SonicWall client tries something else.
You may find it out, if you activate the protocol in TMG, put your cleint IP as "Client IP" and see, what the log sais. It maybe that you need some more ports than HTTPS.
Even your error should be there. But you can see what happens around.
In the Sonicwall Clients, do you use the IP or the name of the target? If you use an IP address, I assume it is a public one, right?
And also keep in mind, that the SonicWall may need a rule to let you in. And the SonicWall sees the public IP of TMG, not your client IP. At least the message says now, that the TMG is not able to establish a connection to the SonicWall, what can happen, if the SonicWall just drops the package.
You may find it out, if you activate the protocol in TMG, put your cleint IP as "Client IP" and see, what the log sais. It maybe that you need some more ports than HTTPS.
Even your error should be there. But you can see what happens around.
In the Sonicwall Clients, do you use the IP or the name of the target? If you use an IP address, I assume it is a public one, right?
And also keep in mind, that the SonicWall may need a rule to let you in. And the SonicWall sees the public IP of TMG, not your client IP. At least the message says now, that the TMG is not able to establish a connection to the SonicWall, what can happen, if the SonicWall just drops the package.
ASKER
Bernbi,
yes, I 'm using the SonicWall "Internet" IP Adress. I am NOT able to ping it ! But I am able to connect to it if I am turning ma NIC of, connect to Internet via my iPhone hotspot. So my guesse is, that there is something between TMG and SonicWall.
May I need to contact the SonicWall Admin to make that there is nor rule stopping me to connect to the sonicWall.
This could take some time...
Regards
Martin
yes, I 'm using the SonicWall "Internet" IP Adress. I am NOT able to ping it ! But I am able to connect to it if I am turning ma NIC of, connect to Internet via my iPhone hotspot. So my guesse is, that there is something between TMG and SonicWall.
May I need to contact the SonicWall Admin to make that there is nor rule stopping me to connect to the sonicWall.
This could take some time...
Regards
Martin
It is not a bad idea at all to talk to the other side, because the admin on the SonicWall can see, what reaches the SonicWall and what maybe wrong.
From your side, enable the log for connections from your client (and / or) connections to the DestinationIP (SonicWall) to see, which connections are made, if there are related denied connections and which rule is responsibe for the request.
You client established a connection via HTTP, but there is also a VPN tunnel, and it is possible that subsequent connections are handled by a different rule and then denied.
Also try to ping the SonicWall, when connected via IPhone. If it is not possible, the ping is disabled on the SonicWall, but if it works, TMG should be able too. Nevertheless there is a system rule which determines, if TMG can ping out at all or not. If you can ping any other target, this rule is enabled.
From your side, enable the log for connections from your client (and / or) connections to the DestinationIP (SonicWall) to see, which connections are made, if there are related denied connections and which rule is responsibe for the request.
You client established a connection via HTTP, but there is also a VPN tunnel, and it is possible that subsequent connections are handled by a different rule and then denied.
Also try to ping the SonicWall, when connected via IPhone. If it is not possible, the ping is disabled on the SonicWall, but if it works, TMG should be able too. Nevertheless there is a system rule which determines, if TMG can ping out at all or not. If you can ping any other target, this rule is enabled.
ASKER
Bernbi,
yep, I'll follow the way to talk to SonicWall Admin- Maybe we can come togehter and go on with the option to setup a site-to-site VPN instead of using the desktop client. This would be definitly my preferred solution.
I've less time to check whether I am able to ping via iPhone, but I can ping lots of other targets right from my PC and from the TMG itself so my geuss is that the system rule is enabled.
Thanks for your idea sharing - will keep you in the loop when I know a bit more :-)
Regards
Martin
PS: Pls. be so gentle and accept that I will not setup the thread as it is right know as solved, ok ? As soon as I was in touch with the SonicWall Guy and hopefully be able to solve it, I'll let you know.
yep, I'll follow the way to talk to SonicWall Admin- Maybe we can come togehter and go on with the option to setup a site-to-site VPN instead of using the desktop client. This would be definitly my preferred solution.
I've less time to check whether I am able to ping via iPhone, but I can ping lots of other targets right from my PC and from the TMG itself so my geuss is that the system rule is enabled.
Thanks for your idea sharing - will keep you in the loop when I know a bit more :-)
Regards
Martin
PS: Pls. be so gentle and accept that I will not setup the thread as it is right know as solved, ok ? As soon as I was in touch with the SonicWall Guy and hopefully be able to solve it, I'll let you know.
No problem, come back if you have more information...:-)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Solution did not solved the issue, just a Workaround.
Have a look here:
http://o-www.sonicwall.com/app/projects/file_downloader/document_lib.php?t=TN&id=15