SRX

Dear Community,

Today we tried to setup Dynamic VPN with Radius authentication to give our domain users access to our internal trusted network.

I will post our configuration we made for the Dynamic tunnel below, so maybe somebody could have a look through if we missed anything?

But maybe its also just a bad idea to use the Windows 7 included VPN Client to connect to the SRX240?

In fact we are not able to connect to our SRX240 by using the Windows 7 VPN client, but we are also unsure how to configure the Windows 7 VPN client properly.

So one of the questions is at least: Is it possible (or maybe not recommended) by using the Windows based VPN Client (withing Windows Network and Sharing Center)?

Is there any free alternative client software for Windows 7?

Here is our configuration we made on our SRX240 (running  JUNOS 11.4R5.5):

Of course system service ike in host-inbound traffic for our untrust interface "reth15.0" is enabled.

----------------------------------------------------------------------------------------------------------------------------

set security ike policy ike-dyn-vpn-policy mode aggressive

set security ike policy ike-dyn-vpn-policy proposal-set standard

set security ike policy ike-dyn-vpn-policy pre-shared-key ascii-text "OUR_SECRET_KEY"

set security ike gateway dyn-vpn-local-gw ike-policy ike-dyn-vpn-policy

set security ike gateway dyn-vpn-local-gw dynamic hostname dynvpn

set security ike gateway dyn-vpn-local-gw dynamic ike-user-type group-ike-id

set security ike gateway dyn-vpn-local-gw dynamic connections-limit 10

set security ike gateway dyn-vpn-local-gw external-interface reth15.0    (Our untrust interface)

set security ike gateway dyn-vpn-local-gw xauth access-profile dyn-vpn-access-profile

set security ipsec policy ipsec-dyn-vpn-policy proposal-set standard

set security ipsec vpn dyn-vpn ike gateway dyn-vpn-local-gw

set security ipsec vpn dyn-vpn ike ipsec-policy ipsec-dyn-vpn-policy

set security policies from-zone untrust to-zone trust policy dyn-vpn-policy match source-address any

set security policies from-zone untrust to-zone trust policy dyn-vpn-policy match destination-address any

set security policies from-zone untrust to-zone trust policy dyn-vpn-policy match application any

set security policies from-zone untrust to-zone trust policy dyn-vpn-policy then permit tunnel ipsec-vpn dyn-vpn

set access profile dyn-vpn-access-profile authentication-order radius
set access profile dyn-vpn-access-profile radius-server <our Radius Server IP> secret "Our Radius Secret"
set access firewall-authentication web-authentication default-profile dyn-vpn-access-profile

set security dynamic-vpn access-profile dyn-vpn-access-profile

----------------------------------------------------------------------------------------------------------------------------

We tried almost all variations of Windows VPN client configuration, but no tunnel is etablished successfully so far.

Assuming our Radius server (Windows 2008R2 NPS) is working correctly.

We are thankful for every hint.

Maybe there is a best practice on how to establish VPN connections between Windows 7 machines and the SRX240 by using Radius Authentication?

Maybe we have also missed something on our Radius Server, but so far we could not see any successful Phase 1 for the Dynamic VPN initiated from the Win7 client... so i guess there is either an issue with the Win7 VPN Client config or with our SRX240 Dynamic VPN config as listed above.

Best regards,

IT-onBase

Hi,

are you trying to connect from Win7 directly or using Junos Pulse client? Direct connection from Win7 won't go..

You have geat application note regarding setting up Dynamic VPN on SRX. Check attachment.

Regards

Damjan

Attachment(s)

dynamic-vpn-appnote-junos10.4-v21.pdf   777 KB 1 version

Hi SharePoint, All,

I was trying to connect directly from Win7 VPN Client.

But as that won't works, i've downloaded the Junos Pulse Client V3, but still not able to connect.

By going through the troubleshooting guides I've found, that the SRX240 dynamic-vpn is not accessible via https.

If I point my browser to https://<untrust-interface-IP>/dynamic-vpn then it just goes back to my J-Web interface which is working, but why i am not able to see the dynamic-vpn page?

I've checked the http.conf by using

cat /var/jail/etc/httpd.conf

But i was not able to found any line:  IKEGatewayInterfaces <interfaces>

The output is:

--------------------------------------------------------------------------------------------------------------------------------

root@mysrx240% cat /var/jail/etc/httpd.conf
ErrorLog /var/log/httpd.log
LogLevel 2
DirectoryIndex index.php
ThreadLimit 5
LimitClients 400
LimitRequestBody 268435456
LimitUploadSize 268435456
LimitRequestFields 512
LimitRequestFieldSize 1048576
LimitResponseBody 10000000
LimitStageBuffer 8192
LimitChunkSize 8192
LimitUrl 30000
IdleTimeout 3600
Timeout 600
User nobody
Group nobody
TypesConfig /jail/etc/mime.types
Expires 5184000 text/html application/x-javascript image/png image/jpeg text/css application/x-shockwave-flash image/gif
TimeZone Europe/Zurich
KeepAlive on
KeepAliveTimeout 120
MaxKeepAliveRequests 200
SetConnector netConnector
Listen 80
Listen [::]:80
HTTPInterfaces fxp0.0|
LoadModule sslModule mod_ssl
Listen 443
Listen [::]:443
<VirtualHost *:443>
  ServerName "mysrx240"
  DocumentRoot "/html"
  SSLEngine on
  SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
  SSLProtocol ALL -SSLV2
  SSLCertificateFile "/var/db/certs/system-cert/system-generated.cert"
  SSLCertificateKeyFile "/var/db/certs/system-key-pair/system-generated.priv"
</VirtualHost>
<VirtualHost [::]:443>
  ServerName "mysrx240"
  DocumentRoot "/html"
  SSLEngine on
  SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
  SSLProtocol ALL -SSLV2
  SSLCertificateFile "/var/db/certs/system-cert/system-generated.cert"
  SSLCertificateKeyFile "/var/db/certs/system-key-pair/system-generated.priv"
</VirtualHost>
HTTPSInterfaces fxp0.0|reth15.0|reth2.0|
Chroot /jail
ServerRoot "/"
ServerName "myrsx240"
DocumentRoot "/html"
LoadModule chunkFilter mod_chunk
AddFilter chunkFilter
LoadModule uploadFilter mod_upload
AddInputFilter uploadFilter
UploadDir /tmp
UploadAutoDelete off
LoadModule dvpnFilter mod_dvpn
AddFilter dvpnFilter
LoadModule webauthFilter mod_webAuth
AddInputFilter webauthFilter
LoadModule jauthHandler mod_jauth
AddHandler jauthHandler
LoadModule cgiHandler mod_cgi
AddHandler cgiHandler php
LoadModule fileHandler mod_file
AddHandler fileHandler html htm gif jpeg png pdf js gz css jpg xml swf xml exe cab cli jar ico ""

--------------------------------------------------------------------------------------------------------------------------------

I'm thankful for any further hints...

For some testings, I've created a Dynmic-VPN by using the J-Web "Task" -> "Configure VPN" -> Launch VPN Wizard.

Then i chose Remote Access and followed the steps.

The interesting thing, at the end i was able to access https://<IP>/dynamic-vpn but no longer the J-Web under https://<IP>

When i checked the httpd.conf again at the end (last line) there was: IKEGatewayInterfaces reth15.0

It looked like the Dynamic-VPN should basically work now... but when i tried to establish the connection with the Junos Pulse Client to just the IP, it asked me for the user and password and i entered the one I had created with the VPN Wizard.

Then it was just saying "establishing connection" but never succeded.

After some minutes i canceled it and changed back my SRX config to what is was before the Wizard.

At least i was able again to access the J-Web.

I'm really at the end of my latin right now... could that be such difficult to have a remote access vpn connection by using any vpn client in order to get through the SRX to any or mutliple protected networks?

some update:

I configured my SRX240 now for the use with the NCP Secure Client - Juniper Edition.

The Tunnel is now establishing successful, but I'm not able to get any traffic from client to the remoted protected network.

From my point of view everything is set, but maybe i missed something..?

It would be great if anybody could have a look through my config any maybe has a hint for me why no traffic is going through the tunnel?

As already mentioned we have an active-actice cluster. The untrust interface is reth15.0 and the trust interface is reth2.0.

I had to choose manual IP in NCP Client, as we dont have a DHCP server yet, i just give the client one of the IP's within the trust network 10.200.1.30.

The authentication is made with a RADIUS Server and it seems to working also fine.

So, the tunnel itself seems to working fine, except that no traffic is going through...

---------------------------------------------------------------------------------------------

interfaces {

    ge-0/0/2 {
        gigether-options {
            redundant-parent reth2;
        }
    }

    ge-0/0/15 {
        gigether-options {
            redundant-parent reth15;
        }
    }

    reth2 {
        redundant-ether-options {
            redundancy-group 1;
        }
        unit 0 {
            family inet {
                address 10.200.1.1/24;
            }
        }
    }

    reth15 {
        redundant-ether-options {
            redundancy-group 1;
        }
        unit 0 {
            family inet {
                address <ourPublicIP>/28;
            }
        }
    }

security {
    ike {

        proposal PSK-DES-MD5-DH2 {
            authentication-method pre-shared-keys;
            dh-group group2;
            authentication-algorithm md5;
            encryption-algorithm des-cbc;
            lifetime-seconds 28800;

        }

        policy dialup-ike-policy {
            mode aggressive;
            proposals PSK-DES-MD5-DH2;
            pre-shared-key ascii-text "SECRET";
        }

        gateway dialup-ike {
            ike-policy dialup-ike-policy;
            dynamic {
                hostname "user@juniper.net";
                connections-limit 10;
                ike-user-type shared-ike-id;
            }
            external-interface reth15.0;
            xauth access-profile xauth-users;
        }
    }

    ipsec {

        proposal ESP-3DES-SHA256 {
            protocol esp;
            authentication-algorithm hmac-sha-256-128;
            encryption-algorithm 3des-cbc;
        }
        policy dialup-ipsec-policy {
            perfect-forward-secrecy {
                keys group2;
            }
            proposals ESP-3DES-SHA256;
        }

        vpn dialup-vpn {
            ike {
                gateway dialup-ike;
                ipsec-policy dialup-ipsec-policy;
            }
            establish-tunnels on-traffic;
        }
    }

    flow {

        }
        tcp-mss {
            ipsec-vpn {
                mss 1350;
            }
        }
    }

    policies {

        from-zone trust to-zone untrust {

            policy default-permit-trust-untrust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                    log {
                        session-init;
                    }
                    count;
                }
            }
        }

        from-zone untrust to-zone trust {
            policy dialup-unt-tr {
                match {
                    source-address any;
                    destination-address TRUST_ALL_HOSTS_MGMT_NETWORK_10.200.1.0/24;
                    application any;
                }
                then {
                    permit {
                        tunnel {
                            ipsec-vpn dialup-vpn;
                        }
                    }
                }
            }

            policy default-untrust-trust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    deny;
                    log {
                        session-init;
                    }
                }
            }
        }

    zones {

        security-zone trust {
            tcp-rst;
            address-book {
                address TRUST_ALL_HOSTS_MGMT_NETWORK_10.200.1.0/24 10.200.1.0/24;

            }
            host-inbound-traffic {
                system-services {
                    http;
                    https;
                    ping;
                    ssh;
                    telnet;
                    snmp;
                }
            }
            interfaces {
                reth2.0;
            }
        }

        security-zone untrust {

            screen untrust-screen;
            host-inbound-traffic {
                system-services {
                    ping;
                    https;
                    ssh;
                    ike;
                }
            }
            interfaces {
                reth15.0;

access {
    profile xauth-users {
        authentication-order radius;
        session-options {
            client-idle-timeout 180;
        }
        radius-server {
            <RADIUS-SERVER-IP {
                port 1812;
                secret "RADIUS-SERVER SECRET";
            }
        }
    }
}

---------------------------------------------------------------------------------------------

And here is the log from NCP client:

---------------------------------------------------------------------------------------------

14.11.2012 12:56:32  IPSec: Start building connection
14.11.2012 12:56:32  Ike: Outgoing connect request AGGRESSIVE mode - gateway=OUR-PUBLIC-IP : PROFILENAME
14.11.2012 12:56:32  Ike: XMIT_MSG1_AGGRESSIVE - PROFILENAME
14.11.2012 12:56:32  Ike: RECV_MSG2_AGGRESSIVE - PROFILENAME
14.11.2012 12:56:32  Ike: IKE phase I: Setting LifeTime to 28800 seconds
14.11.2012 12:56:32  Ike: Turning on XAUTH mode - IT-onBase
14.11.2012 12:56:32  Ike: IkeSa negotiated with the following properties -
14.11.2012 12:56:32    Authentication=XAUTH_INIT_PSK,Encryption=DES,Hash=MD5,DHGroup=2,KeyLen=0
14.11.2012 12:56:32  Ike: IT-onBase ->Support for NAT-T version - 9
14.11.2012 12:56:32  Ike: Turning on NATD mode - PROFILENAME - 1
14.11.2012 12:56:32  IPSec: Final Tunnel EndPoint is:OURPUBLICIP
14.11.2012 12:56:32  Ike: XMIT_MSG3_AGGRESSIVE - PROFILENAME
14.11.2012 12:56:32  Ike: IkeSa negotiated with the following properties -
14.11.2012 12:56:32    Authentication=XAUTH_INIT_PSK,Encryption=DES,Hash=MD5,DHGroup=2,KeyLen=0
14.11.2012 12:56:32  Ike: phase1:name(PROFILENAME) - connected
14.11.2012 12:56:32  SUCCESS: IKE phase 1 ready
14.11.2012 12:56:32  IPSec: Phase1 is Ready,AdapterIndex=0,IkeIndex=49,LocTepIpAdr=0.0.0.0,AltRekey=1
14.11.2012 12:56:32  IkeXauth: RECV_XAUTH_REQUEST
14.11.2012 12:56:32  IkeXauth: XMIT_XAUTH_REPLY
14.11.2012 12:56:32  IkeXauth: RECV_XAUTH_SET
14.11.2012 12:56:32  IkeXauth: XMIT_XAUTH_ACK
14.11.2012 12:56:32  IkeCfg: name <IT-onBas> - IkeXauth: enter state open
14.11.2012 12:56:32  SUCCESS: Ike Extended Authentication is ready
14.11.2012 12:56:32  IPSec: Quick Mode is Ready: IkeIndex = 00000031 , VpnSrcPort = 10954
14.11.2012 12:56:32  IPSec: Assigned IP Address: 10.200.1.30
14.11.2012 12:56:32  IPSec: Gateway IP Address: 0.0.0.0
14.11.2012 12:56:32  IkeQuick: XMIT_MSG1_QUICK - PROFILENAME
14.11.2012 12:56:32  IkeQuick: Received Notify(IT-onBase) -> remote is reducing LifeTime to 3600
14.11.2012 12:56:32  IkeQuick: RECV_MSG2_QUICK - PROFILENAME
14.11.2012 12:56:32  IkeQuick: Turning on PFS mode(PROFILENAME) with group 2
14.11.2012 12:56:32  IkeQuick: XMIT_MSG3_QUICK - PROFILENAME
14.11.2012 12:56:32  IkeQuick: phase2:name(PROFILENAME) - connected
14.11.2012 12:56:32  SUCCESS: Ike phase 2 (quick mode) ready
14.11.2012 12:56:32  IPSec: Created an IPSEC SA with the following characteristics -
14.11.2012 12:56:32    IpSrcRange=[10.200.1.30-10.200.1.30],IpDstRange=[10.200.1.0-10.200.1.255],IpProt=0,SrcPort=0,DstPort=0
14.11.2012 12:56:32  IPSec: connected: LifeDuration in Seconds = 2520 and in KiloBytes = 0
14.11.2012 12:56:32  IPSec: Connected to PROFILENAME on channel 1.
14.11.2012 12:56:32  PPP(Ipcp): connected to IT-onBase with IP Address: 10.200.1.30
14.11.2012 12:56:32  SUCCESS: IpSec connection ready
14.11.2012 12:56:35  SUCCESS: Link -> <PROFILENAME> IP address assigned to IP stack - link is operational.

Thanks for any hints...

Hi,

What is the interface range you are passing to your clients?  You may need to proxy-arp on reth.2 for this if the IP Pool range if it is in the same range as your trust subnet: 10.200.1.0/24

Hi MMcD,

I'm not sure as i don't have set an IP-Pool for this tunnel so far (it was not described in the NCP guide from here:

http://www.ncp-e.com/fileadmin/pdf/service_support/NCP_QuickInstallationGuide-NCPwithJuniperJunos.pdf

So, im quite open (and a bit new in VPN) at this time to find any way to get the clients automaticaly assigned an ip-address.

Right now i just conifgured the NCP client with a manual IP (by choosing manually any free IP from the Trust network)

If in understood you right, i should set up proxy-arp for this as long as I'm using a manually IP for the client which matches the remote network?

What would be the best way, to have automatically assigne IP's to the NCP client?

By using an IP-Pool defined in SRX, or by using DHCP server connected to the RADIUS server?

Maybe in the RADIUS server itself possible, too?

update:

I've setup an ip-pool like this:

access {
    profile xauth-users {
        authentication-order radius;
        address-assignment {
            pool dyn-vpn-address-pool;
        }
        session-options {
            client-idle-timeout 180;
        }
        radius-server {
            <RADIUS-SERVER-IP> {
                port 1812;
                secret "RADIUS-SECRET";
            }
        }
    }
    address-assignment {
        pool dyn-vpn-address-pool {
            family inet {
                network 10.100.200.0/24;
                range dyn-vpn-range {
                    low 10.100.200.2;
                    high 10.100.200.254;

and made the proxy-arp for reth2.0 like this:

        proxy-arp {
            interface reth2.0 {
                address {
                    10.100.200.2/32 to 10.100.200.254/32;

Then I've changed the NCP client to "local IP-address" (before it was manually local IP-address).

Now the clients gets successfully an IP from the defined pool. It took the first available IP 10.100.200.2.

When i try to ping a host from client within the remote network i still have no reply.

So Tx is counting up in NCP client, but Rx is still on 0.

Still no traffic trough the tunnel... what could be wrong?

Hi,

There is loads of stuff on RADIUS out there:

http://www.juniper.net/techpubs/software/junos/junos91/swconfig-system-basics/radius-attributes-and-juniper-networks-vsas-supported-by-theaaa-service-framework.html

Or (much easier for a beginner)you can let the SRX dish out the IP and DNS settings like below,  note the proxy arp setting on the internal LAN interface as the client IPs are in the same subnet

    dynamic-vpn {
        access-profile dyn-vpn-access-profile;
        clients {
            all {
                remote-protected-resources {
                    192.168.1.0/24;
                }
                remote-exceptions {
                    0.0.0.0/0;
                }
                ipsec-vpn dyn-vpn;
                user {
                    client1;
                    client2;
                }
            }

    address-assignment {
        pool dyn-vpn-address-pool {
            family inet {
                network 192.168.1.0/24;
                range r1 {
                    low 192.168.1.15;
                    high 192.168.1.75;
                }
                xauth-attributes {
                    primary-dns 2.3.4.5/32;
                }
            }
        }
    }
    nat {
        proxy-arp {
            interface ge-0/0/1.0 {
                address {
                    192.168.1.15/32 to 192.168.1.75/32;
                }
            }
        }
    }

Yes, so try the following:

user@srx#set security nat proxy-arp interface reth2.0 address <your-given-ip>

Thank you MMcD for all your help so far.

But as mentioned in my last post, I've created an ip-pool for vpn (different IP's than the remote protected network), set the proxy arp according to the vpn ip-pool under the reth2.0 (remote protected network trust).

But I'm still not able to get with any traffic through the tunnel.

Maybe we should summarize it:

- The tunnel itself is established successfully (and running now stable since more than 1h).

- The RADIUS authentication seems to be working properly, as the tunnel was established successfully by using a user from our AD

- the NCP client receives the first available IP-address defined by the vpn IP pool, also that seems to be working

- proxy-arp for the ip-addresses used by the vpn IP pool has been set for the remote protected network

...but still no traffic wants through the tunnel...

i think i have missed to set tup a dns server for the vpn IP pool so far, but think it should not be neccessary as long as i only want to use IP's instead of URL's.. not sure about...

on the same srx240 we have also a site-to-site tunnel which is running since a long time perfectly.

but where else could the no-traffic thorugh tunnel issue resists for the client-to-site tunnel?

- maybe a policy problem? (should it have a bidirectional one?)

or at the end just a client problem with NCP client?

Hi,

OK, I suggest you enable a trace and see where the traffic is going:

http://kb.juniper.net/InfoCenter/index?page=content&id=KB16108

Make a couple of packet-filters based on your IP ranged of your trust zone and your client vpn ip range.

I think thats a good idea..

So for the beginning i tried to just setup a basic trace to capture debug flow:

# set security flow traceoptions file flow-trace
# set security flow traceoptions flag basic-datapath

# set security flow traceoptions packet-filter f0 destination-prefix 10.200.1.0/24

# set security flow traceoptions packet-filter f1 destination-prefix 10.100.200.0/24

# commit and-quit

After that I've tried to view the flow-trace log:

 > show log flow-trace


But receiving the error:

error: could not resolve file: flow-trace

What I am doing wrong?

I've deleted and recreated the trace and now it seems to be working.

Not sure if i have the right filters with:

# set security flow traceoptions packet-filter f0 destination-prefix 10.200.1.0/24 (Untrust)

# set security flow traceoptions packet-filter f0 destination-prefix 10.100.200.0/24 (VPN Client IPs)

In the output i cannot see any entry of any of the client VPN IP's.

Maybe i would also need some little help about how to set the filter...

Try this:

# set security flow traceoptions packet-filter f0 source-prefix 10.200.1.0/24


# set security flow traceoptions packet-filter f0 destination-prefix 10.100.200.0/24


# set security flow traceoptions packet-filter f1 source-prefix 10.100.200.0/24

# set security flow traceoptions packet-filter f1 destination-prefix 10.200.1.0/24

allright, thanks for the filter usage...

i've set it up as described in your last post and the output is:

If i do a simple ping from client where the vpn client is running to one of the hosts in the protected trust network i have only this entry:

Nov 14 22:14:39 22:14:21.830791:CID-2:RT : SPU invalid session id 00000000

There are hundrets iof entries, but all are the same like this... a problem with the session somehow..?

If i do the ping from a host in the trust network to the vpn client ip which has been assigned to the client from the vpn ip-pool, then the output looks a bit more complex:

-- output in the attachment--
 

Attachment(s)

trace-flow.txt   23 KB 1 version

OK that would tell me the traffic is never getting to the srx properly at all, if the trace is empty. 

How does your routing table look on your client machine?  if it is a windows machine can you open a command line and type "route print" and post it.

22:14:39 22:14:21.830791:CID-2:RT : SPU invalid session id 00000000 - I have seen these myself on various devices after upgrading to 11.4 and above.  Not sure what causes it.  I have yet to see it cause performance issues.

Here you can see that the traffic is routed out to your gateway when you try to ping to the vpn clients.

routed (x_dst_ip 10.100.200.13) from trust (reth2.0 in 1) to reth15.0, Next-hop: 91.213.133.14

Thats quite strange...

Could it maybe an issue with the next-hop. As from the trace it says Next-hop: 91.213.133.14.

This is configured as a static route for 0.0.0.0/0 (it was done a long time before i took over the administration) and it seems that this-one is the ISP gateway.

route 0.0.0.0/0 next-hop 91.213.133.14

On our untrust interface we have not only a single IP, we have public /28 subnet.

Could that maybe the problem?

But the VPN connection itself is working fine, except that no traffic is going through...

Attached also the current log from NCP Client.

While the NCP VPN connection is established my client's route table looks like this:

C:\>route print
===========================================================================
Interface List
 44...02 00 17 46 30 14 ......NCP Secure Client Virtual NDIS6 Adapter
 30...88 53 2e 35 eb 6f ......Bluetooth Personal Area Network
 15...02 80 37 ec 02 00 ......Ericsson F5521gw for TOSHIBA Mobile Broadband Netw
ork Adapter
 14...88 53 2e 35 eb 6c ......Microsoft Virtual WiFi Miniport Adapter #2
 13...88 53 2e 35 eb 6c ......Microsoft Virtual WiFi Miniport Adapter
 12...88 53 2e 35 eb 6b ......Intel(R) Centrino(R) Advanced-N 6230
 11...e8 9d 87 5d aa 2b ......Intel(R) 82579LM Gigabit Network Connection
 25...00 50 56 c0 00 01 ......VMware Virtual Ethernet Adapter for VMnet1
 26...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8
  1...........................Software Loopback Interface 1
 24...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 27...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 28...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
 33...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #5
 29...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #6
 32...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #7
 43...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #8
 47...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #9
 16...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.58     20
     10.100.200.0    255.255.255.0         On-link      10.100.200.6    257
     10.100.200.6  255.255.255.255         On-link      10.100.200.6    257
   10.100.200.255  255.255.255.255         On-link      10.100.200.6    257
       10.200.1.0    255.255.255.0       10.0.3.113     10.100.200.6      3
       10.200.1.0    255.255.255.0     10.100.200.7     10.100.200.6      3
     91.213.133.1  255.255.255.255      192.168.1.1     192.168.1.58     20
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.1.0    255.255.255.0         On-link      192.168.1.58    276
     192.168.1.58  255.255.255.255         On-link      192.168.1.58    276
    192.168.1.255  255.255.255.255         On-link      192.168.1.58    276
    192.168.153.0    255.255.255.0         On-link     192.168.153.1    276
    192.168.153.1  255.255.255.255         On-link     192.168.153.1    276
  192.168.153.255  255.255.255.255         On-link     192.168.153.1    276
    192.168.206.0    255.255.255.0         On-link     192.168.206.1    276
    192.168.206.1  255.255.255.255         On-link     192.168.206.1    276
  192.168.206.255  255.255.255.255         On-link     192.168.206.1    276
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link     192.168.206.1    276
        224.0.0.0        240.0.0.0         On-link     192.168.153.1    276
        224.0.0.0        240.0.0.0         On-link      192.168.1.58    276
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link      10.100.200.6    257
  255.255.255.255  255.255.255.255         On-link     192.168.206.1    276
  255.255.255.255  255.255.255.255         On-link     192.168.153.1    276
  255.255.255.255  255.255.255.255         On-link      192.168.1.58    276
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0       10.200.0.1  Default
===========================================================================

Attachment(s)

NCP_client_log.txt   4 KB 1 version

10.200.1.0    255.255.255.0     10.0.3.113          10.100.200.6      3
10.200.1.0    255.255.255.0     10.100.200.7     10.100.200.6      3

This looks odd,

If you tracert to 10.200.1.x what does it reveal when vpn is connected?

The tracert from the client while VPN is connected goes nowhere....

I tried to tracert an existing host within the trust network >host 10.200.1.99

Tracing route to 10.200.1.99 over a maximum of 30 hops

  1     *        *        *     Request timed out.
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.

And here is the output from NCP LAN Emulation Trace while tracert (attachment)

Attachment(s)

NCP_Tracer.txt   30 KB 1 version

by the way: there was one thing i could not setup as described in the NCP Junos config guide:

Security Policy for Internet Traffic

---------------------------------------------

edit security policies from-zone trust to-zone untrust

set policy any-permit then permit source-nat interface

as from other posts, this seems no longer to be working.

but the fact is, we have a source nat rule "any-out" from source 0.0.0.0/0 to 0.0.0.0 interface

could that maybe cause the issue i have?

and if yes, should i do a something like a except source nat rule dor the vpn-clients 10.100.200.0/24?

The NAT rule shouldnt effect your clients, as the connections are initiated from the client to the srx and onto to the trust zone.  If you try and connect outbound as with your ping above, then the traffic will just go out your default gateway.

Im a bit stumped, the traffic never appears to get to the SRX if your trace is good.

Maybe enable another trace without any filter also, ping in from the connected client, then disable the trace.  It will generate a lot of data, but search for your client IP address in it,  if you cannot see it, then you can be sure your client traffic is not hitting the SRX.

Once you connect can you see the ipsec and ike established from the srx?

user@srx>show security ike sa

user@srx>show security ipsec sa

Interesting, i made the full flow trace, and yes the file was big, but no IP was listed, neither my client's public ip nor the client's assigned vpn ip, but the NCP client still means it is connected.

I disconnected and reconnected the NCP client a few times, made some pings and tracerts while the tunnel was connected and deactived afterwards again the flow trace and had a look into.. but still no clients IP listed.

The output from the Ike sa and ipsec sa shows that both are up:

root@mysrx240> show security ike sa
node1:
--------------------------------------------------------------------------
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address               
12778314 UP    dd1f4c08dbb714ee  3de003ae64687d71  Aggressive     21X.22X.214.XX

root@mysrx240> show security ipsec sa
node1:
--------------------------------------------------------------------------
  Total active tunnels: 2
  ID    Algorithm       SPI      Life:sec/kb  Mon vsys Port  Gateway
  <133955600 ESP:3des/sha256 64dee3ad 2774/ unlim - root 10954 21X.22X.214.XX
  >133955600 ESP:3des/sha256 66ed7acb 2774/ unlim - root 10954 21X.22X.214.XX
  <133955600 ESP:3des/sha256 d484de6 2774/ unlim - root 10954 21X.22X.214.XX
  >133955600 ESP:3des/sha256 349babf5 2774/ unlim - root 10954 21X.22X.214.XX

And thats the real strange thing... phase1 and phase2 seems really to working fine... the tunnel is there...

but i dont understand, why there are two tunnels to my clients public ip: 21X.22X.214.XX?

and the traffic seems to be dropped somewhere....  i think more and more it must be related to the client somehow...

But on another Win7 machine (brand-new installed) with NCP and the same settings the behavior is exactely the same...

And yes, for testings of course Ive disabled all Anti-Virus, Firewall etc... on the clients... and the tunnel is connecting successful...   but anywhere on the client or the SRX the traffic is dropped or missrouted...