cancel
Showing results for 
Search instead for 
Did you mean: 

SA_Setting_Problem

esper_
Occasional Contributor

SA_Setting_Problem

Good Morning.

I have just bought a new SA 2500 for SSL VPN and a new SSG5 for sperate a DMZ.

Network Diagram

                                                                         --------SA2500(Interal Port)

                                                                         |

Internet-----(Untrucst)SSG140(DMZ)-----switch(DMZ)-----(Untrust)SSG5(Trust)-----switch(Internal)--------Internal Resource

Detail SSG 140 DMZ interface  : 192.168.0.254 SA2500 Internal interface : 192.168.0.200 SSG5 Untrust interface  : 192.168.0.253 SSG5 Trust Interface  : 192.168.90.253

 

 

I try to set the SA 2500, I notice that I can connect the SSL VPN (network connect) outside, and I use the whatismyip to check the global IP, the result is the public IP of the location of SA 2500, but I can not access any internal resource in the DMZ and the internal resource.

In SA2500, I do the setting with below step 1.create the user(User001) in the [auth servers>system local>Users], 2.create the roles(UserRoles01) in the [User roles], and enable the feature. 3.create the realms(HKPool)in the [User Realms], and set the auth server to use system local, role mapping UserRoles01 to * user. 4.create a new signing in page and map */HK_User/ -->New Page-->HKPool, and enable the multiple user sessions. 5.In [Resource Policies->Network connect->Network connect access control], I see there is default *:* all roles allow. 6.In [Resource Policies->Network connect->NC Connection Profiles], I set the 192.168.30.2-192.168.30.100 IP pool for all roles. 7.In [Resource Policies->Network connect-> Split-tunneling Networks], I set the Resources range is 192.168.30.0/24(VPN Pool), 192.168.0.0/24(DMZ), 192.168.90.0/24(Internal). 8.In [Netowork->Network Connect], I set the Network Connect Server IP Address is 192.168.30.200.

After I set that, I can can access the sa2500 from outside but can not access the machine in DMZ and internal, Do I miss any setting?

 

12 REPLIES 12
spuluka
Super Contributor

Re: SA_Setting_Problem

Since your SA2500 is in the DMZ you will also need both routing and policies to allow the traffic on the SSG firewall in addition to your setup on the SA2500.

 

Is your connected DMZ network include the 192.168.30 address pool you assigned to your clients?

If not, you need to add a static route to the DMZ interface with the SA2500 ip address as the next hop.

 

Create policies from DMZ pool of your SA2500 to the servers and other devices you need that address pool to access.

 

If you think both routing and policy on the SSG is correctly in place, then the next step would be to capture the connection attempts using debug flow on the firewall.  Setup a capture with your address pool as source and the server as destination then generate the traffic and review the results.

 

DEBUG FLOW BASIC :
==================

Prepare the tool
1. undebug all - we are assuring that the debug utility is not already running.
2. get ffilter - we would expect to get no response. This tells us we have not set up any flow filters as of yet. If you should see filters listed you can delete them with unset ffilter.

Setup the capture
3. set ffilter src-ip x.x.x.x(computer A) dst-ip x.x.x.x(computer B)
  set ffilter src-ip x.x.x.x(Computer B) dst-ip x.x.x.x(computer A) by doing this we can observe the packets flowing in each direction and where any possible problems may be. Basically we want to define the end points of communication.

Capture the traffic
5. clear db - this will clear the debugging cache.
6. debug flow basic - this turns the debugging utility on.
7. initiate the traffic you are interested in capturing.

Pull the data
8. undebug all - turns the utility back off.  
9. get db stream - this is the actual packet capture output that we want.

Remove the setup
10.unset ffilter 0 - this will need to be done twice, once for each filter that we set up earlier.
11.clear db - this will clear the cache.

 

Steve Puluka BSEET - IP Architect - DQE Communications Pittsburgh, PA (Metro-Ethernet & ISP) - http://puluka.com/home
esper_
Occasional Contributor

Re: SA_Setting_Problem

Dear Steve

Thanks for your reply. If I can not access the local resource in DMZ, do it also the problem of routing? Thanks.

jayLaiz_
Super Contributor

Re: SA_Setting_Problem

Hi,

 

What is the dafault gateway on the ssl VPN's internal port.

 

On that default gateway, add a static route with next hop as 192.168.30.0/24 pointing to the SSL VN internal interface IP and check.

 

Regards,

Jay

tomsaurer_
Occasional Contributor

Re: SA_Setting_Problem

I would make sure that your DMZ has a route to the IP addresses that you're assigning to the clients.

esper_
Occasional Contributor

Re: SA_Setting_Problem


@jayLaiz wrote:

Hi,

 

What is the dafault gateway on the ssl VPN's internal port.

 

On that default gateway, add a static route with next hop as 192.168.30.0/24 pointing to the SSL VN internal interface IP and check.

 

Regards,

Jay


 

 

 

Thanks for your reply, I follow your instructor, and now I can ping to the resource in DMZ, but can not access DMZ's resource, even I set untrust to DMZ allow all in SSG140, still can not do any access except ping. Would I set any other thing wrong?

jayLaiz_
Super Contributor

Re: SA_Setting_Problem

Hi,

 

Can you do a tracert and see where the packet is dropping.

 

Thanks,

Jay

esper_
Occasional Contributor

Re: SA_Setting_Problem

Dear JayLaiz

Sorry for late reply. I do not in office these day.

Today I do the tracert and get the result like below.

 

 

C:\Users\ >tracert 192.168.0.128

 

Tracing route to 192.168.0.128 over a maximum of 30 hops

 

  1    36 ms    40 ms    39 ms  192.168.30.200

  2    41 ms    41 ms    38 ms  192.168.0.128

 

Trace complete.

 

 

192.168.30.200 is the network connect server ip address(SA2500).

THe 192.168.0.128 is the notebook, this notebook is open the rdp, telnet, etc service, I can access it in the 192.168.0.0 network but not from the ssl vpn, only can ping it though the ssl vpn.

Do it the problem of ACL or the routing? (I allow allow traffic untrust to trust and trust to untrust.)

 

Thanks 

 

 

 

jayLaiz_
Super Contributor

Re: SA_Setting_Problem

Hi,

 

Looks like a ACL problem as the traceroute is completing successfully. Is there a rule on firewall to allow traffic from ssl vpn internal interface to trust.

 

Thanks,

Jay

esper_
Occasional Contributor

Re: SA_Setting_Problem

Thanks for your reply.^^

 

I think so, but now I set the ACL in the below.

SSG140

Untrust to DMZ

Any to Any permit

 

DMZ to Untrust

Any to Any permit

 

 

 

SSG5

Untrust to Trust

Any to Any permit

 

Trust to Untrust

Any to Any permit

 

 

 

SA2500

In [Resource Policies->Network connect-> Split-tunneling Networks], I set the Resources range is 192.168.30.0/24(VPN Pool), 192.168.0.0/24(DMZ)

In [Resource Policies->Network connect-> ACL], Default is allow *:*, I add Allow icmp://*:* and tcp://*:*

 

Basicly I approve all the traffic, do something I miss?