Hi all,

I am trying (and failing) to configure Filter Based Forwarding on a SRX300 running 15.1X49-D140.2 . In a nutshell I am trying to forward traffic for a small number of hosts towards a RPi running an OpenVPN connection, to use as their default outbound connection.

I have followed this KB article:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB23300

.... and ended up with the following config:

firewall {                              
    family inet {
        filter ARM02-OPENVPN {
            term 0 {
                from {
                    source-address {
                        10.83.30.5/32;
                        10.83.30.12/32;
                    }
                }
                then {
                    count ARM02-OPENVPN-COUNTER;
                    syslog;
                    routing-instance ARM02-ROUTER;
                }
            }
            term 1 {
                then accept;
            }
        }
    }
}

routing-options {
    interface-routes {
        rib-group inet ARM02-ROUTER;
    }
    rib-groups {
        ARM02-ROUTER {
            import-rib [ inet.0 ARM02-ROUTER.inet.0 ];
        }
    }
} 
routing-instances {
    ARM02-ROUTER {
        instance-type forwarding;
        routing-options {
            static {
                route 0.0.0.0/0 next-hop 10.83.42.1;
            }
        }
    }                                   
} 

interfaces {
    irb {
        unit 30 {
            description INSIDE_VLAN;
            family inet {
                filter {
                    input ARM02-OPENVPN;
                }
                address 10.83.30.254/24;
                address 10.83.48.254/24;
            }
        }
    }
}

I can see the filter is working:

Filter: ARM02-OPENVPN                                          
Counters:
Name                                                Bytes              Packets
ARM02-OPENVPN-COUNTER                              821189                 9257

The routing looks good:

Routing table: ARM02-ROUTER.inet
Internet:
Destination        Type RtRef Next hop           Type Index    NhRef Netif
default            user     0 b8:27:eb:e1:e0:a4  ucst     1370     3 ge-0/0/3.0

...the outbound interface and MAC address match the RPi.

However whilst the counter 'ARM02-OPENVPN-COUNTER' increments, if I run tcpdump on the RPi eth0 interface I don't see ant of the HTTPS packets I am expecting. The SRX seems to be correctly detecting the packets on ingress but then dropping them on egress.

I am still in my early days of junos so troubleshooting skills are certainly lacking!

Any help is much appreciated.

cheers,

Seb.

Hi, Seb

Is the /32 prefix on the filter expected? meaning that only 10.83.30.5 and 10.83.30.12 will be affected by this FBF config?

The routing looks fine, what about the security-policies? are they permitting the traffic? Check if a session is getting created:

> show security flow session destination-prefix [dst_adress] source-prefix [src_address] destination-port 443

I build SRX clusters pretty often and thought i'll documenting the process. I have typed up this article (not tested yet), but am confident it covers all the steps needed to build a cluster on the SRX platform.

The "how to" or Step by Step" Juniper SRX300, 320, 340, 345 clustering guide.

Minimum Junos Version: 12.1X47-D10

• SRX300 Control Ports: Connect ge-0/0/1 on node 0 to ge-0/0/1 on node 1. < -- Becomes the fxp0 interfaces
• SRX300 Fabric Ports: Connect ge-0/0/0 on node 0 to ge-0/0/0 on node 1. < -- Becomes the fab0/1 interfaces

Depending on your SRX model this will be the port re-numbering scheme applied:

• SRX300 : ge-0/0/1 interface on node 1 changes to ge-1/0/1
• SRX320 : ge-0/0/1 interface on node 1 changes to ge-3/0/1
• SRX340/345 : ge-0/0/1 interface on node 1 changes to ge-5/0/1

 General Notes:

1. Interconnect the control interfaces: connect interface srx0 ge-0/0/1 to srx1 ge-0/0/1
2. Interconnect the fabric interfaces: connect interface srx0 ge-0/0/2 to srx1 ge-0/0/2
3. Connect the physical interfaces you intend to send network traffic over directly to the same switch initially.
4. Connect Network Interfaces to the switch: connect interface ge-0/0/3 and ge-0/0/4 to your switch for both srx0 and srx1.
5. !! Do not put the switch ports into any kind of LAG configuration !!
6. Configure the switch ports as access ports (no vlanning) to simplify initial trouble shooting, once the cluster and ports are functional you can switch ports to trunk and pass multiple vlans.
7. All configurations are done via the SRX direct or usb-to-serial management port.

 On srx0 and srx1:

Clear the config on both devices and set the root password.
set system root authentication plaintext-password
set protocols l2-learning global-mode switching
commit

On srx0:

set chassis cluster cluster-id 1 node 0 reboot

On srx1:

set chassis cluster cluster-id 1 node 1 reboot

Review:

run show chassis cluster status

Cluster ID: 1
Node                  Priority          Status    Preempt  Manual failover

Redundancy group: 0 , Failover count: 1
    node0                   100         primary        no       no
    node1                   1           secondary      no       no

Redundancy group: 1 , Failover count: 1
    node0                   0           primary        no       no
    node1                   0           secondary      no       no

After the cluster is built configure management:

set groups node0 system host-name srx300-node0
set groups node0 interfaces fxp0 unit 0 family inet address 10.1.1.1/24
set groups node1 system host-name srx300-node1
set groups node1 interfaces fxp0 unit 0 family inet address 10.1.1.2/24
set apply-groups "${node}"
commit

Review:

run show interfaces terse | match fxp0

fxp0                    up    up
fxp0.0                  up    up   inet     10.1.1.1/24

Configure the chassis cluster fabric:

set interfaces fab0 fabric-options member-interfaces ge-0/0/2
set interfaces fab1 fabric-options member-interfaces ge-1/0/2
commit

Review:

run show interfaces terse | match fab

ge-0/0/2.0              up    up   aenet    --> fab0.0
ge-1/0/2.0              up    up   aenet    --> fab1.0
fab0                    up    up
fab0.0                  up    up   inet     30.17.0.200/24
fab1                    up    up
fab1.0                  up    up   inet     30.18.0.200/24

run show chassis cluster data-plane interfaces

fab0:
 Name Status 
 ge-0/0/2 up 
fab1:
 Name Status 
 ge-1/0/2 up 

Verification:

run show chassis cluster data-plane statistics

Services Synchronized:
    Service name                              RTOs sent    RTOs received
    Translation context                       0            0
    Incoming NAT                              0            0
    Resource manager                          0            0
    DS-LITE create                            0            0
    Session create                            1428919      0
    IPv6 session create                       0            0
    Session close                             537639       0
    IPv6 session close                        0            0
    Session change                            130005       0
    IPv6 session change                       0            0
    ALG Support Library                       121          0
    Gate create                               0            0
    Session ageout refresh requests           0            10241
    IPv6 session ageout refresh requests      0            0
    Session ageout refresh replies            9513         0
    IPv6 session ageout refresh replies       0            0
    IPSec VPN                                 9            0
    Firewall user authentication              0            0
    MGCP ALG                                  0            0
    H323 ALG                                  0            0
    SIP ALG                                   0            0
    SCCP ALG                                  0            0
    PPTP ALG                                  0            0
    JSF PPTP ALG                              0            0
    RPC ALG                                   0            0
    RTSP ALG                                  0            0
    RAS ALG                                   0            0
    MAC address learning                      0            0
    GPRS GTP                                  0            0
    GPRS SCTP                                 0            0
    GPRS FRAMEWORK                            0            0
    JSF RTSP ALG                              0            0
    JSF SUNRPC MAP                            0            0
    JSF MSRPC MAP                             0            0
    DS-LITE delete                            0            0
    JSF SLB                                   0            0
    APPID                                     0            0
    JSF MGCP MAP                              0            0
    JSF H323 ALG                              0            0
    JSF RAS ALG                               0            0
    JSF SCCP MAP                              0            0
    JSF SIP MAP                               0            0
    PST_NAT_CREATE                            0            0
    PST_NAT_CLOSE                             0            0
    PST_NAT_UPDATE                            0            0
    JSF TCP STACK                             0            0
    JSF IKE ALG                               0            0

Clear stats if needed:

run clear chassis cluster data-plane statistics

Configure the chassis cluster interfaces:

set chassis cluster redundancy-group 0 node 0 priority 100
set chassis cluster redundancy-group 0 node 1 priority 1
set chassis cluster redundancy-group 1 node 0 priority 100
set chassis cluster redundancy-group 1 node 1 priority 1
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/3 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-1/0/3 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-1/0/4 weight 255
set chassis cluster reth-count 2
commit

 Configure redundant interfaces:

set interfaces ge-0/0/3 gigether-options redundant-parent reth0
set interfaces ge-1/0/3 gigether-options redundant-parent reth0

*******************************************************************
Access Port Mode:
set interfaces reth0 redundant-ether-options redundancy-group 1
set interfaces reth0 unit 0 family inet address 172.30.111.254/24

OR

Trunk Port Mode:
set interfaces reth0 vlan-tagging
set interfaces reth0 redundant-ether-options redundancy-group 1
set interfaces reth0 unit 903 family inet address 172.30.111.254/24

Or 

Trunk Port Mode Multiple Sub Interfaces:
set interfaces reth0 vlan-tagging
set interfaces reth0 unit 903 family inet address 172.30.111.254/24
set interfaces reth0 unit 904 family inet address 172.16.1.254/24
*******************************************************************

set interfaces ge-0/0/4 gigether-options redundant-parent reth1
set interfaces ge-1/0/4 gigether-options redundant-parent reth1
set interfaces reth1 redundant-ether-options redundancy-group 1
set interfaces reth1 unit 0 family inet address 172.16.1.254/24

commit
*******************************************************************
Same Applies for Access/Trunk or Mutliple Sub Interfaces as above.
The rest of this configuartion is built around access interfaces.
*******************************************************************

Add the interfaces to the security zone:

set security zones security-zone trust host-inbound-traffic system-services ping
set security zones security-zone trust interfaces reth0.0

set security zones security-zone untrust host-inbound-traffic system-services ping
set security zones security-zone untrust interfaces reth1.0
commit

Verification:

run show chassis cluster status

Cluster ID: 1
Node                       Priority     Status    Preempt  Manual failover

Redundancy group: 0 , Failover count: 1
    node0                   100         primary   no       no
    node1                   1           secondary no       no

Redundancy group: 1 , Failover count: 1
    node0                   0           primary   no       no
    node1                   0           secondary no       no

#run show chassis cluster interfaces

Control link name: em0

Redundant-ethernet Information:
    Name         Status      Redundancy-group
    reth0        Up          1
    reth1        Up          1

Interface Monitoring:
    Interface         Weight    Status    Redundancy-group
    ge-0/0/3          255       Up        1
    ge-0/0/4          255       Up        1
    ge-1/0/3          255       Up        1
    ge-1/0/4          255       Up        1

Verification:

run show chassis cluster statistics
Control link statistics:
    Control link 0:
        Heartbeat packets sent: 2276
        Heartbeat packets received: 2280
        Heartbeat packets errors: 0
Fabric link statistics:
    Child link 0
        Probes sent: 2272
        Probes received: 597
Services Synchronized:
    Service name                              RTOs sent    RTOs received
    Translation context                       0            0
    Incoming NAT                              0            0
    Resource manager                          6            0
    Session create                            161          0
    Session close                             148          0
    Session change                            0            0
    Gate create                               0            0
    Session ageout refresh requests           0            0
    Session ageout refresh replies            0            0
    IPSec VPN                                 0            0
    Firewall user authentication              0            0
    MGCP ALG                                  0            0
    H323 ALG                                  0            0
    SIP ALG                                   0            0
    SCCP ALG                                  0            0
    PPTP ALG                                  0            0
    RPC ALG                                   0            0
    RTSP ALG                                  0            0
    RAS ALG                                   0            0
    MAC address learning                      0            0
    GPRS GTP                                  0            0

Verification:

run show chassis cluster control-plane statistics
Control link statistics:
    Control link 0:
        Heartbeat packets sent: 2294
        Heartbeat packets received: 2298
        Heartbeat packets errors: 0
Fabric link statistics:
    Child link 0
        Probes sent: 2290
        Probes received: 615

Verification:

run show chassis cluster status redundancy-group 1

Cluster ID: 1
    Node               Priority    Status    Preempt  Manual failover

	Redundancy group: 1, Failover count: 1
    node0              100          primary   no       no
    node1              50           secondary no       no

Create a test policy:

!! NOTE You need to delete/disable this before going into production !!

set security policies global policy FullAccessTest match source-address any
set security policies global policy FullAccessTest match destination-address any
set security policies global policy FullAccessTest match application any
set security policies global policy FullAccessTest then permit

Troubleshooting logs:

run show log jsrpd
run show log chassisd
run show log messages
run show log dcd

Still to complete:

1) Configure security policies to allow traffic between zones.
2) Configuring NAT'ting if required.
3) Configure routing-options.
4) Configure untrust zone screening

Hopefully that works for you

Thanks jonashauge, it worked fine!

I'm not sure if i get what you mean about swfab... I have interface 0/0 has HA Mgmt interface (fxp0), 0/1 as Control Link (fxp1) and 0/2 as Ha Fabric Link (fab)...

Useful, thanks!

Hi Trasgu,

the swfab0 and swfab1 are used if you actually want ethernet-switching on your SRX cluster... Then you will need a fabric link for "ordinary" traffic and a fabric link for layer2 (vlanX->vlanX) traffic. In this scenario you configure swfab0 and swfab1 on top of fab0 and fab1.

But in general you are usually better of keeping layer2 switching away from your SRX cluster - keep that traffic in your switches :-)

Can anyone help point me in the right direction.  I've been searching for documentation or examples on redistrubting BGP routes over to OSPF.  

I have my cloud providers being delivered to us over two interfaces, each with there own logical vlan.  I'm receiving BGP routes from Microsoft and Google but i'd like to pass these over to our core router which is using OSPF over two other redundant connections.  

On Cisco it's basicly just:

router bgp 100   redistribute ospf 1

Not sure what the SRX context is.  

Hi,

thanks for the reply.

Yes currently I only want two hosts from 10.83.30.0/24 to be re-directed. The security policy looks like:

policy ARM02 {
    match {
        source-address any-ipv4;
        destination-address ARM02;
        application [ junos-dns-udp junos-dns-tcp junos-ssh junos-https junos-http ];
    }
    then {
        permit;
    }
}

I know this works fine as ARM02 runs pi-hole and I can browse to the webGUI for that serivce on HTTPS without issue.

Running your suggested command gives me:

show security flow session source-prefix 10.83.30.12    
Session ID: 10908, Policy name: INSIDE-TO-OUTSIDE/4, Timeout: 1722, Valid
  In: 10.83.30.12/43221 --> 216.58.213.74/443;tcp, Conn Tag: 0x0, If: irb.30, Pkts: 15, Bytes: 3526, 
  Out: 216.58.213.74/443 --> x.x.x.x/24804;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 11, Bytes: 4156, 

Session ID: 12969, Policy name: INSIDE-TO-OUTSIDE/4, Timeout: 1462, Valid
  In: 10.83.30.12/50593 --> 157.240.1.32/443;tcp, Conn Tag: 0x0, If: irb.30, Pkts: 10, Bytes: 1249, 
  Out: 157.240.1.32/443 --> x.x.x.x/20051;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 8, Bytes: 3842, 

Session ID: 12977, Policy name: INSIDE-TO-OUTSIDE/4, Timeout: 1790, Valid
  In: 10.83.30.12/38191 --> 64.233.184.188/5228;tcp, Conn Tag: 0x0, If: irb.30, Pkts: 47, Bytes: 3641, 
  Out: 64.233.184.188/5228 --> x.x.x.x/9314;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 34, Bytes: 12745, 

Session ID: 13034, Policy name: INSIDE-TO-OUTSIDE/4, Timeout: 1720, Valid
  In: 10.83.30.12/55815 --> 216.58.206.46/443;tcp, Conn Tag: 0x0, If: irb.30, Pkts: 11, Bytes: 914, 
  Out: 216.58.206.46/443 -->x.x.x.x/5889;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 11, Bytes: 4649, 
Total sessions: 4

So it looks like traffic is leaving via ge-0/0/0 which is connected to the internet link, which is not the ge-0/0/3 that the routing table indicates should be used!?

Any ideas?

cheers,

Seb.

Hi Munozj,

If the BGP routes are already present in the routing-table of the SRX, you can use an Export-policy to distribute those routes via OSPF to other peers.

1. Create an Export-policy to match the BGP routes in the routing-table:

[edit policy-options]
user@srx# show
	policy-statement BGP-INTO-OSPF {    term BGP-ONLY {        from protocol bgp;        then {            accept;        }  
2. Apply the Export-policy under OSPF:

[edit protocols]
user@srx# show
	ospf {
	    export BGP-INTO-OSPF;    area 0.0.0.0 {        interface ae0.0        interface ge-0/0/0.0

3. Confirm the routes advertisement (via LSAs) over OSFP:

	> run show ospf database advertising-router self

You can see and example to redistribute OSPF in to BGP in the following link. I know if the opposite but see that they follow the same steps.

https://www.juniper.net/documentation/en_US/junos/topics/example/routing-policy-security-opspf-route-into-bpg-routing-table-injecting.html

I hope this info is helpful.

Lets see how is the SRX processing the packets,

Configure flow traceoptions for HTTPS packets coming from 10.83.30.5 to the ARM02 address:

set security flow traceoptions file TEST
set security flow traceoptions flag basic-datapath
set security flow traceoptions packet-filter TEST source-prefix 10.83.30.5/32
set security flow traceoptions packet-filter TEST destination-prefix [ARM02_ADDRESS]
set security flow traceoptions packet-filter TEST destination-port 443

Commit the configuration and try sending traffic from .5 and after that see that data was saved to the file TEST:

> show log TEST

Please share with us the information saved to TEST file. Ideally attach the file itself.

Hi Eugene,

You mean that IPv6 traffic is already flowing properly through the SRX but you are not seeing the sessions?

Can you post the following commands:

• show security flow status
• show security flow session summary family inet6
• show security flow session family inet6

SRX240> show security flow status
  Flow forwarding mode:
    Inet forwarding mode: flow based
    Inet6 forwarding mode: flow based
    MPLS forwarding mode: drop
    ISO forwarding mode: drop
  Flow trace status
    Flow tracing status: off

SRX240> show security flow session summary family inet6
Valid sessions: 0
Pending sessions: 0
Invalidated sessions: 0
Sessions in other states: 0
Total sessions: 0

SRX240> show security flow session family inet6
Total sessions: 0

Thx for any replies....

Eugene,

If the traffic is flowing properly, I will say that this is a software bug or limitation due to the old Junos version installed on the device. Opening a case with JTAC will be of no use because the version 11.4 is out of support since 06/21/2015  so I will highly suggest an upgrade to the recommended junos version:

https://kb.juniper.net/KB21476 

It will not be a surprised that this is a bug, I was checking the 11.4R7 release notes and there was a bug related to IPv6 flows:

On all branch SRX Series devices, the flow bytes counters tracked on a per-interface basis were incorrect for IPv6 flows, and flow output bytes statistics were reversed to the source or destination interfaces. [PR740911: This issue has been resolved.]

https://www.juniper.net/documentation/en_US/junos11.4/information-products/topic-collections/release-notes/11.4/junos-release-notes-11.4r7.pdf

Maybe by using security-policy logging you can see the  IPv6 sessions getting created/denied :

https://www.juniper.net/documentation/en_US/junos/topics/concept/security-system-log-message-overview.html

https://kb.juniper.net/InfoCenter/index?page=content&id=KB16509&actp=METADATA

I doubt there was support for this on 11.4 but its worth trying it if you need this information.

Hope it helps!

Hello.

I have a quite annoying problem. The most annoying thing about it is that it's somewhat erratic. For some users the VPN always works, but some report that the VPN gets properly connected but no traffic is coming through. And even for those clients for whom it doesn't work it happens to work sometimes (after some five, ten or twenty reconnections).

On the VPN server's side everything looks ok. The SA's are created, the dynvpn users are reported as connected, even show security flow session for client's IP shows traffic (both directions!). But the traffic does not show on client's machine. So, for example, the ping shows no response even though flow session on the SRX shows traffic counters in both directions.

What's most puzzling about it is that it happens only for some clients (and I cannot find any common factor here) and not always, so I have no clue how to debug it. To make things harder - on my laptop everything works perfectly OK.

For example, the same user that reports VPN "not working" from his virtual machine with Windows 10 says that it's working perfectly OK from his linux host (via patched vpnc client). I think that only Windows 10 machines are troubled with this issue but not all of them. My fresh "debug" instance which I installed lately specificaly for troubeshooting this problem (normaly I use W8.1) works OK. I thought that maybe it has something to do with McAfee agent on users' laptops but my W10 also has it and still works good.

So I'm completely stuck.

If anyone has any idea what might be causing this... Or at least where to start looking.

Relevant excerpts from config:

security {
    ike {
        policy Dyn-vpn-P3 {
            mode aggressive;
            proposal-set standard;
            pre-shared-key ascii-text "edited out"; 
        }
        gateway dyn-vpn-local-test-gw {
            ike-policy Dyn-vpn-P3;
            dynamic {
                hostname vpngw;
                ike-user-type group-ike-id;
            }
            external-interface ge-0/0/0.0;
            aaa {
                access-profile vpn-ldap;
            }
        }
    ipsec {
        policy test-dyn-vpn-policy {
            perfect-forward-secrecy {
                keys group2;
            }
            proposal-set standard;
        }
        vpn test-dyn-vpn {
            ike {
                gateway dyn-vpn-local-test-gw;
                ipsec-policy test-dyn-vpn-policy;
            }
        }
    }
    alg {
        dns disable;
        ftp disable;
        msrpc disable;
        sunrpc disable;
        rtsp disable;
        talk disable;
        tftp disable;
        pptp disable;
        ike-esp-nat {
            enable;
        }
    }
    dynamic-vpn {
        access-profile vpn-ldap;
        clients {
            OFFICE {
                remote-protected-resources {
                    172.16.100.0/24;
                    10.0.0.0/24;
                }
                ipsec-vpn test-dyn-vpn;
                user-groups {
                    G-VPN_Office;
                }
            }
            ENG {
                remote-protected-resources {
                    10.0.0.0/24;
                    172.16.0.0/16;
                    10.0.3.0/24;
                }
                ipsec-vpn test-dyn-vpn;
                user-groups {
                    G-VPN_Eng;
                }
            }
            all {
                remote-protected-resources {
                    192.168.10.0/24;
                    10.0.0.0/24;
                    172.16.0.0/24;
                    10.0.3.0/24;
                    172.16.100.0/24;
                }
                ipsec-vpn test-dyn-vpn;
                user-groups {
                    G-VPN;
                    G-VPNLAB;
                }
            }
        }
    }
    screen {
        ids-option untrust-screen {
            icmp {
                ping-death;
            }
            ip {
                source-route-option;
                tear-drop;
            }
            tcp {
                syn-flood {
                    alarm-threshold 1024;
                    attack-threshold 200;
                    source-threshold 1024;
                    destination-threshold 2048;
                    timeout 20;
                }
                land;
            }
        }
    }
    policies {
        from-zone OUTSIDE to-zone junos-host {
            policy IPSec-VPN {
                match {
                    source-address any;
                    destination-address IP-external;
                    application [ junos-ike junos-ike-nat isakmp junos-https esp esp-nat-t ];
                }
                then {
                    permit;
                    log {
                        session-init;
                        session-close;
                    }
                    count;
                }
            }
        }
        from-zone OUTSIDE to-zone SRV {
            policy VPN-access-SRV {
                match {
                    source-address VPN-clients-POOL1; 
                    destination-address NET-SRV;
                    application any;
                }
                then {
                    permit;
                    log {
                        session-init;
                        session-close;
                    }
                    count;
                }
            }
        }
        from-zone OUTSIDE to-zone LAB {
            policy LAB-VPN-access {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit {
                        tunnel {
                            ipsec-vpn test-dyn-vpn;
                        }
                    }
                    count;
                }
            }
        }
[...] (there are more specific entries from zone OUTSIDE to various internal zones permitting traffic from VPN-clients-POOL1)
        default-policy {
            deny-all;
        }
    }
        security-zone OUTSIDE {
            host-inbound-traffic {
                system-services {
                    ike;
                    ping;
                    https;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                ge-0/0/0.0;
            }
        }
    }
}
access {
    profile vpn-ldap {
        authentication-order ldap;
        address-assignment {
            pool VPN-POOL;
        }
        ldap-options {
            base-distinguished-name dc=whatever,dc=com;
            search {
                search-filter samaccountname=;
                admin-search {
                    distinguished-name cn=edited out;
                    password "edited out"; ## SECRET-DATA
                }
            }
        }
        ldap-server {
            10.0.0.12;
        }
    }
    address-assignment {
        pool VPN-POOL {
            family inet {
                network 10.0.222.0/24;
                range POOL1 {
                    low 10.0.222.11;
                    high 10.0.222.200;
                }
                xauth-attributes {
                    primary-dns 10.0.0.12/32;
                    secondary-dns 10.0.0.13/32;
                }
            }
        }
    }
    firewall-authentication {
        pass-through {
            default-profile vpn-ldap;
        }
        web-authentication {
            default-profile vpn-ldap;
        }
    }
}

Hello again,

OK so the traceoptions look like:

show configuration security flow traceoptions    
file TEST;
flag basic-datapath;
packet-filter TEST {
    source-prefix 10.83.30.12/32;
    destination-prefix 10.83.42.1/32;
    destination-port 443;
}

..but the log file looks like:

show log TEST    
Oct 12 10:07:27 CS7-HQ-FW02 clear-log[20259]: logfile cleared

...as a sanity test if I directly connect to https://10.83.42.1 from 10.83.30.12 the log file shows loads of output, but just relying on the FBF nothing happens.

Is this looking like a bug?

cheers,

Seb.

We have a problem with our ADSL interface not re-establishing when there is a drop. Allthough our line has been tested and proved to be working i am not convinced that this isn't the reason that our ADSL interface drops off. We have tried both SRX110 and SRX210 with ADSL module and the same thing happens. Once the interface drops it does not restablish sync and we need to reboot the router to re-sync the ADSL. Is there something missing in the config that may help as i belive the drop to minimal with no major downtime i.e - 1 second. Here is the config if anyone has experience about the ADSL configs on SRX's and can help with this?

at-1/0/0 {
description "Backup ADSL WAN link";
traceoptions {
flag all;
}
encapsulation atm-pvc;
atm-options {
vpi 0;
}
dsl-options {
operating-mode auto;
}
unit 0 {
encapsulation atm-ppp-vc-mux;
vci 0.38;
ppp-options {
chap {
default-chap-secret "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"; ## SECRET-DATA
local-name "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
passive;
}
}
family inet {
negotiate-address;