SRX

So I too want to do some port forwarding. I have a SRX210 running 11.4R10.3 behind a cable modem, so its externally facing interface (fe-0/0/3.0 for now) uses dhcp. I would like to forward traffic going to the external IP, port 10024, to go to a machine in 10.0.0.100 port 22. Based on what I read in http://forums.juniper.net/t5/SRX-Services-Gateway/SRX-PAT-Question/td-p/33640, http://forums.juniper.net/t5/SRX-Services-Gateway/SRX-port-forwarding-translation/td-p/100942," target="_blank">http://forums.juniper.net/t5/SRX-Services-Gateway/Port-forwarding-NAT-on-DHCP-assigned-external-address/td-p/55632, http://forums.juniper.net/t5/SRX-Services-Gateway/SRX-port-forwarding-translation/td-p/100942, and what I gathered from http://kb.juniper.net/InfoCenter/index?page=content&id=TN81&actp=LIST, I did

 

root@uranus# show security                                                   
address-book {                                                               
    global {                                                
        address strangepork 10.0.0.100/32;                  
    }                                                       
}
nat {
    source {
        rule-set trust-to-untrust {
            from zone trust;
            to zone untrust;
            rule source-nat-rule {
                match {
                    source-address 0.0.0.0/0;
                }
                then {
                    source-nat {
                        interface;
                    }
                }
            }
        }
    }
    destination {
        pool ssh_strangepork_pool {
            address 10.0.0.100/32 port 22;
        }                               
        rule-set SSH-UNTRUST-TO-TRUST {
            from zone untrust;
            rule DEST-NAT {
                match {
                    destination-address 0.0.0.0/0;
                    destination-port 10024;
                }
                then {
                    destination-nat pool ssh_strangepork_pool;
                }
            }
        }
    }
}
policies {
    from-zone trust to-zone untrust {
        policy trust-to-untrust {
            match {
                source-address any;
                destination-address any;
                application any;
            }
            then {                      
                permit;
            }
        }
    }
    from-zone untrust to-zone trust {
        policy ssh-strangepork-inbound-pol {
            match {
                source-address any;
                destination-address strangepork;
                application junos-ssh;
            }
            then {
                permit;
            }
        }
    }
}
zones {
    security-zone untrust {
        screen untrust-screen;
        interfaces {
            fe-0/0/3.0 {
                host-inbound-traffic {
                    system-services {
                        dhcp;
                        tftp;
                    }                   
                }
            }
        }
    }
}

 Since the port is being reported as not open when i try to connect from outside, I must have missed a step. Does anyone know what that step is?

Only thing I'm seeing right off the bat would be your actual D-Nat rule.  Instead of saying destination address 0.0.0.0 you need to make this your srx's external IP.  D-Nat evaluates the destination address field of a packet for translation, so just fill that part in with your srx's public IP. 

Thanks for the reply. When I was searching for answers to this I found the threads http://forums.juniper.net/t5/SRX-Services-Gateway/SRX-PAT-Question/td-p/33640 and http://forums.juniper.net/t5/SRX-Services-Gateway/Port-forwarding-NAT-on-DHCP-assigned-external-address/td-p/55632 (I posted those links in the original post... badly, so the links weren't working) dealing with the same situation I had: destination nat with dhcp. Both seem to recommend to set the destination-address to 0.0.0.0/0 because while using dhcp you really do not know what that address might be. So, you have to punt a bit in the name of... science!

 

That said, I have the router in a test lab, so let's set that IP to the one given by the router for the testlab (192.168.55.169):

 

root@uranus# show security nat destination                                  
pool ssh_strangepork_pool {
    address 10.0.0.100/32 port 22;
}
rule-set SSH-UNTRUST-TO-TRUST {
    from zone untrust;
    rule DEST-NAT {
        match {
            destination-address 192.168.55.169/32;
            destination-port 10024;
        }
        then {
            destination-nat pool ssh_strangepork_pool;
        }
    }
}

[edit]
root@uranus# run show security nat destination rule all                     
Total destination-nat rules: 1
Total referenced IPv4/IPv6 ip-prefixes: 1/0
 
Destination NAT rule: DEST-NAT             Rule-set: SSH-UNTRUST-TO-TRUST 
  Rule-Id                    : 1  
  Rule position              : 1
  From zone                  : untrust
    Destination addresses    : 192.168.55.169  - 192.168.55.169
 
  Destination port           : 10024 
  Action                     : ssh_strangepork_pool 
  Translation hits           : 6

[edit]
root@uranus# 

 So far so good. Now if we use nmap from a machine in the test lab (192.168.55.113) to probulate uranus, we have:

nmap -sV -P0 -p10024 192.168.55.169

[...]
Nmap scan report for 192.168.55.169
Host is up (0.0017s latency).
PORT      STATE    SERVICE VERSION
10024/tcp filtered unknown
MAC Address: 00:26:88:12:5C:43 (Juniper Networks)

 i.e. port 10024 is not open.

The config looks fine to me.  That's what I use on my SRX220 at home with multiple D-NAT services, the ports get translated appropriately.  Do you have any firewall filters in place?  They are examined first before D-Nat and security policy so if you've got one configured you might want to take a look at that. 

 

Beyond that, you could try making a custom application and referencing that in your security policy from untrust-to-trust rather than using the pre-defined junos-ssh application.  Honestly this shouldn't be the problem though.

 

Of course, I would just check the end device at 10.0.0.100 and confirm that its listening on port 22 and doesn't have a firewall itself.

 

The best way to test all of this is to check the security flow session to see if its even getting as far as security policy evaluation.  When you run your nmap test or ssh test or whatever it is, issue the following command:

 

>show security flow session source-prefix 192.168.55.113

 

Post the output of this in your next reply.

I think you hit the nail on the head; I knew the d-nat was evaluated before the security policies but I did not think on the firewall rules.

 

So, right now I only have the default firewall:

root@uranus# run show firewall 

Filter: __default_bpdu_filter__                                

[edit]
root@uranus# 

I created a firewall filter,

root@uranus# show firewall                                                  
filter strangefilter {
    term 1 {
        from {
            destination-port 10024;
        }
        then accept;
    }
}

[edit]
root@uranus# 

which I hope accepts traffic coming to port 10024 from nowhere in special, and then applied to the interface I am using for the external one (I am being lazy here):

root@uranus# show interfaces fe-0/0/3          
unit 0 {
    family inet {
        filter {
            input strangefilter;
        }
        dhcp;
    }
}

[edit]
root@uranus# 

 

About the security policy from untrust-to-trust, I forgot I did create a custom application,

root@uranus# show applications 
application ssh_strangepork {
    protocol tcp;
    destination-port 10024;
}

 So let's apply it:

root@uranus# show security policies from-zone untrust to-zone trust 
policy ssh-strangepork-inbound-pol {
    match {
        source-address any;
        destination-address strangepork;
        application ssh_strangepork;
    }
    then {
        permit;
    }
}

 

 I do not seem to be getting anything in the security flow session as I try to ssh from 192.168.55.113 to uranus on port 10024:

root@uranus# run show security flow session source-prefix 192.168.55.113    
Total sessions: 0

[edit]
root@uranus# 

So, I don't think I am out of the woods just yet.  Incidentally the host in 10.0.0.100 is listening on its port 22

Try adding a second term to your strangefilter firewall filter:

 

term 2

     then accept

 

This basically says that any other traffic will be allowed, since if you don't have one it will be denied.

 

OR

 

If you remove all firewall filters does it then work? 

I did try both. Same result as before. Here is the output of show security after I removed the firewall filter altogether and was trying to reach uranus using both ssh and nmap:

root@uranus# run show security flow session source-prefix 192.168.55.113    
Total sessions: 0

[edit]
root@uranus# show firewall 

[edit]
root@uranus# 

 

Hmmm, post your entire config and I'll look through it. 

 

And just to be 100% clear on what we're doing, you're not trying to ssh directly to the srx, you're trying to ssh to a box behind the srx via d-nat, correct? 

 

Can you see ANY security flows at all?  Just do "run show security flow session".

 

Also run "run show interfaces fe-0/0/3.0 terse" and "run show route"

Here is the config sanitized in a rather half-ass way:

root@uranus# show 
## Last changed: 2014-05-22 16:01:07 EDT
version 11.4R10.3;
system {
    host-name uranus;
    domain-name example.com;
    time-zone America/New_York;
    root-authentication {
        encrypted-password "supersecret"; ## SECRET-DATA
    }
    name-server {
        208.67.222.222;
        208.67.220.220;
    }
                                
    services {
        ssh {
            root-login deny;
            protocol-version v2;
        }
        dhcp {
            default-lease-time 3600;
            pool 10.0.0.0/24 {
                address-range low 10.0.0.100 high 10.0.0.250;
                maximum-lease-time 14400;
                default-lease-time 7200;
                domain-name example.com;
                router {
                    10.0.0.2;
                }
            }
            static-binding 00:1f:f3:46:23:90 {
                fixed-address {
                    10.0.0.100;
                }
                host-name strangepork.example.com;
            }
        }                               
    }
    syslog {
        archive size 100k files 3;
        user * {
            any emergency;
        }
        file messages {
            any critical;
            authorization info;
        }
        file interactive-commands {
            interactive-commands error;
        }
    }
    max-configurations-on-flash 25;
    max-configuration-rollbacks 25;
    license {
        autoupdate {
            url https://ae1.juniper.net/junos/key_retrieval;
        }
    }
}
interfaces {                            
    ge-0/0/0 {
        unit 0 {
            family ethernet-switching {
                port-mode trunk;
                vlan {
                    members [ LAN DMZ ];
                }
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }
        }
    }
    fe-0/0/2 {
        unit 0 {
            family ethernet-switching {
                vlan {                  
                    members vlan-trust;
                }
            }
        }
    }
    fe-0/0/3 {
        unit 0 {
            family inet {
                dhcp;
            }
        }
    }
    fe-0/0/4 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }
        }
    }
    fe-0/0/5 {
        unit 0 {                        
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }
        }
    }
    fe-0/0/6 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }
        }
    }
    fe-0/0/7 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }                           
        }
    }
    vlan {
        unit 0 {
            family inet {
                address 192.168.1.1/24;
            }
        }
        unit 2 {
            family inet {
                address 10.0.0.2/24;
            }
        }
        unit 3 {
            family inet {
                address 192.168.3.2/24;
            }
        }
    }
}
security {
    address-book {
        global {                        
            address strangepork 10.0.0.100/32;
        }
    }
    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;
            }
        }                               
    }
    nat {
        source {
            rule-set trust-to-untrust {
                from zone trust;
                to zone untrust;
                rule source-nat-rule {
                    match {
                        source-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
        }
        destination {
            pool ssh_strangepork_pool {
                address 10.0.0.100/32 port 22;
            }
            rule-set SSH-UNTRUST-TO-TRUST {
                from zone untrust;
                rule DEST-NAT {
                    match {
                        destination-address 192.168.55.169/32;
                        destination-port 10024;
                    }
                    then {
                        destination-nat pool ssh_strangepork_pool;
                    }
                }
            }
        }
    }
    policies {
        from-zone trust to-zone untrust {
            policy trust-to-untrust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;             
                }
            }
        }
        from-zone untrust to-zone trust {
            policy ssh-strangepork-inbound-pol {
                match {
                    source-address any;
                    destination-address strangepork;
                    application ssh_strangepork;
                }
                then {
                    permit;
                }
            }
        }
    }
    zones {
        security-zone trust {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {             
                    all;
                }
            }
            interfaces {
                vlan.2 {
                    host-inbound-traffic {
                        system-services {
                            dhcp;
                        }
                    }
                }
            }
        }
        security-zone untrust {
            screen untrust-screen;
            interfaces {
                fe-0/0/3.0 {
                    host-inbound-traffic {
                        system-services {
                            dhcp;
                            tftp;
                        }
                    }                   
                }
            }
        }
        security-zone dmz-zone {
            host-inbound-traffic {
                system-services {
                    ping;
                    dns;
                }
            }
            interfaces {
                vlan.3 {
                    host-inbound-traffic {
                        system-services {
                            dhcp;
                        }
                        protocols {
                            all;
                        }
                    }
                }
            }
        }                               
    }
}
applications {
    application ssh_strangepork {
        protocol tcp;
        destination-port 10024;
    }
}
vlans {
    DMZ {
        vlan-id 3;
        l3-interface vlan.3;
    }
    LAN {
        vlan-id 2;
        l3-interface vlan.2;
    }
    vlan-trust {
        vlan-id 55;
        l3-interface vlan.0;
    }
}
                                        
[edit]
root@uranus# 

 And here are the output of some of the tests:

root@uranus# run show firewall 

Filter: __default_bpdu_filter__                                

[edit]
root@uranus# ... security flow session destination-prefix 192.168.55.169    
Total sessions: 0

[edit]
root@uranus# run show security flow session source-prefix 192.168.55.113    
Total sessions: 0

[edit]
root@uranus# run show interfaces fe-0/0/3.0 terse                           
Interface               Admin Link Proto    Local                 Remote
fe-0/0/3.0              up    up   inet     192.168.55.169/24

[edit]
root@uranus# run show route 

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Access-internal/12] 00:01:44
                    > to 192.168.55.1 via fe-0/0/3.0
10.0.0.2/32        *[Local/0] 07:39:34
                      Reject
192.168.1.1/32     *[Local/0] 07:39:34
                      Reject
192.168.3.2/32     *[Local/0] 07:39:34
                      Reject
192.168.55.0/24    *[Direct/0] 00:43:19
                    > via fe-0/0/3.0
192.168.55.169/32  *[Local/0] 00:43:19
                      Local via fe-0/0/3.0

[edit]
root@uranus#

 Don't aks me how that firewall came back to the router; I thought when I deleted mine uranus would have no protection. I guess I was wrong. 

 

And, you are right: even though I have the ssh service enabled n this router, I am not using it right now; I am accessing it through console. And the d-nat is to reach uranus from the outside (fe-0/0/3), but to get to strangepork. I will add later a separate vlan to use with ssh for management; right now this is not important.

So i noticed under your trust security zone you have "host-inbound-traffic system services all protocols all" defined globally but then under the vlan.2 interface you're only allowing dhcp.  Try getting rid of the "host-inbound-traffic system services dhcp" under the vlan.2 interface and see if that clears up your problem.  Thats probably also the reason why your route table shows 10.0.0.2 as "reject".

Thanks fo rthe suggestion; it does make sense. I guess I have spent way too much time with this and started adding cruft. So, the slimmer version of the security zone trust looks like this:

root@uranus# show security zones security-zone trust                        
host-inbound-traffic {
    system-services {
        all;
    }
    protocols {
        all;
    }
}
interfaces {
    vlan.2;
}

[edit]
root@uranus#

Even though route is still showing 10.0.0.2 as reject and I am still not able to connect to port 10024,

root@uranus# run show route 

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Access-internal/12] 00:03:20
                    > to 192.168.55.1 via fe-0/0/3.0
10.0.0.2/32        *[Local/0] 07:59:35
                      Reject
192.168.1.1/32     *[Local/0] 07:59:35
                      Reject
192.168.3.2/32     *[Local/0] 07:59:35
                      Reject
192.168.55.0/24    *[Direct/0] 01:03:20
                    > via fe-0/0/3.0
192.168.55.169/32  *[Local/0] 01:03:20
                      Local via fe-0/0/3.0

[edit]
root@uranus#

I do think we made progress. Less is more

Is the vlan itself up?  I'm not sure if the host you're trying to connect to is directly connected to the srx or through a switch/trunk, but if the vlan itself isn't up, no traffic will pass.  How do you have your devices cabled up?

 

Display this output for me:

 

"run show interfaces terse" and "run show interfaces vlan.2"

 

Look at the status of the vlan.2 interface.

I believe you need to add interfaces to the vlan.

You've got interface enabled for ethernet-switching and by default these are access ports but these are not assigned to the vlan.

 

This may be the reason why next-hop for vlan.2 is shown as "reject".

In this state, after D-NAT, the route lookup to the destination will fail. The security flow traceoptions would show this, if you don't mind trying that.

 

So, first I want to apologize for taking so long to reply. Long story short, I ended up redoing the test network so I can keep it running until we find my missing link. Current config in router is as follows:

 

## Last changed: 2014-06-02 17:25:28 EDT
version 11.4R10.3;
system {
    host-name uranus;
    domain-name domain.com;
    time-zone America/New_York;
    root-authentication {
        encrypted-password "supersecret"; ## SECRET-DATA
    }
    name-server {
        208.67.222.222;
        208.67.220.220;
    }
    services {
        ssh {
            root-login deny;
            protocol-version v2;
        }
        dhcp {
            default-lease-time 3600;
            pool 10.0.102.0/24 {
                address-range low 10.0.102.100 high 10.0.102.250;
                maximum-lease-time 14400;
                default-lease-time 7200;
                domain-name test.com;
                router {
                    10.0.102.1;
                }
            }
            static-binding 00:11:24:d3:5a:1e {
                fixed-address {
                    10.0.102.100;
                }
                host-name oldpork.test.com;
            }
        }
    }
    syslog {
        archive size 100k files 3;
        user * {
            any emergency;
        }
        file messages {
            any critical;
            authorization info;
        }
        file interactive-commands {
            interactive-commands error;
        }
    }
    max-configurations-on-flash 25;
    max-configuration-rollbacks 25;
    license {
        autoupdate {
            url https://ae1.juniper.net/junos/key_retrieval;
        }
    }
}
interfaces {
    ge-0/0/0 {
        unit 0 {
            family ethernet-switching {
                port-mode trunk;
                vlan {
                    members [ DMZ TEST ];
                }
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }
        }
    }
    fe-0/0/2 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }
        }
    }
    fe-0/0/3 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members EXT;
                }
            }
        }
    }
    fe-0/0/4 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }
        }
    }
    fe-0/0/5 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }
        }
    }
    fe-0/0/6 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members vlan-trust;
                }
            }
        }
    }
    fe-0/0/7 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members TEST;
                }
            }
        }
    }
    vlan {
        unit 0 {
            family inet {
                address 192.168.1.1/24;
            }
        }
        unit 2 {
            family inet {
                address 10.0.0.2/24;
            }
        }
        unit 3 {
            family inet {
                address 192.168.3.2/24;
            }
        }
        unit 102 {
            family inet {
                address 10.0.102.1/24;
            }
        }
    }
}
routing-options {
    static {
        route 0.0.0.0/0 next-hop 10.0.0.1;
    }
}
security {
    address-book {
        global {
            address strangepork 10.0.0.100/32;
            address oldpork 10.0.102.100/32;
            address extip 10.0.0.2/32;
        }
    }
    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;
            }
        }
    }
    nat {
        source {
            rule-set trust-to-untrust {
                from zone trust;
                to zone untrust;
                rule source-nat-rule {
                    match {
                        source-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
            rule-set test-to-untrust {
                from zone test-zone;
                to zone untrust;
                rule source-nat-repeat {
                    match {
                        source-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
        }
        destination {
            pool ssh_pork_pool {
                address 10.0.102.100/32 port 22;
            }
            rule-set SSH-UNTRUST-TO-TRUST {
                from zone untrust;
                rule DEST-NAT {
                    match {
                        destination-address 10.0.0.2/32;
                        destination-port 10024;
                    }
                    then {
                        destination-nat pool ssh_pork_pool;
                    }
                }
            }
        }
    }
    policies {
        from-zone trust to-zone untrust {
            policy trust-to-untrust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone untrust to-zone test-zone {
            policy WAN-TO-TEST {
                match {
                    source-address any;
                    destination-address oldpork;
                    application ssh_strangepork;
                }
                then {
                    permit;
                }
            }
        }
        from-zone test-zone to-zone untrust {
            policy test-to-untrust {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
    }
    zones {
        security-zone trust {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                vlan.0;
            }
        }
        security-zone untrust {
            screen untrust-screen;
            interfaces {
                vlan.2 {
                    host-inbound-traffic {
                        system-services {
                            ping;
                            dhcp;
                        }
                    }
                }
            }
        }
        security-zone dmz-zone {
            interfaces {
                vlan.3 {
                    host-inbound-traffic {
                        system-services {
                            dhcp;
                            ping;
                        }
                    }
                }
            }
        }
        security-zone test-zone {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                vlan.102 {
                    host-inbound-traffic {
                        system-services {
                            dhcp;
                        }
                    }
                }
            }
        }
        security-zone interfaces;
    }
}
applications {
    application ssh_strangepork {
        protocol tcp;
        destination-port 10024;
    }
}
vlans {
    DMZ {
        vlan-id 3;
        l3-interface vlan.3;
    }
    EXT {
        vlan-id 2;
        l3-interface vlan.2;
    }
    TEST {
        vlan-id 102;
        l3-interface vlan.102;
    }
    vlan-trust {
        vlan-id 55;
        l3-interface vlan.0;
    }
}

 As you can see, I set the external/untrusted router IP to 10.0.0.2 and the test machine (the one I want to ssh into from 10.0.0.0/24) is 10.0.102.100. I can reach the internet from that machine,

Macintosh:~ user$ ping 8.8.8.8  
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=47 time=56.795 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=47 time=84.545 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=47 time=55.684 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 55.684/65.675/84.545/13.351 ms
Macintosh:~ user$ 

 I also did clean/redo the config in uranus, so the only rejected route is one I am not using at all:

root@uranus# run show route 

inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 1w1d 00:17:47
                    > to 10.0.0.1 via vlan.2
10.0.0.0/24        *[Direct/0] 1w1d 00:44:25
                    > via vlan.2
10.0.0.2/32        *[Local/0] 1w3d 20:06:45
                      Local via vlan.2
10.0.102.0/24      *[Direct/0] 1w2d 20:02:12
                    > via vlan.102
10.0.102.1/32      *[Local/0] 1w3d 00:14:07
                      Local via vlan.102
192.168.1.1/32     *[Local/0] 1w3d 20:06:45
                      Reject
192.168.3.0/24     *[Direct/0] 1w1d 05:52:37
                    > via vlan.3
192.168.3.2/32     *[Local/0] 1w3d 20:06:44
                      Local via vlan.3

[edit]
root@uranus#

 This is vlan.2 looks like:

root@uranus# run show interfaces vlan.2 
  Logical interface vlan.2 (Index 69) (SNMP ifIndex 532)
    Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.2 ]  Encapsulation: ENET2
    Bandwidth: 0
    Input packets : 83243 
    Output packets: 54392
    Security: Zone: untrust
    Allowed host-inbound traffic : dhcp ping
    Protocol inet, MTU: 1500
      Flags: Sendbcast-pkt-to-re
      Addresses, Flags: Is-Preferred Is-Primary
        Destination: 10.0.0/24, Local: 10.0.0.2, Broadcast: 10.0.0.255

[edit]
root@uranus#

 Am I correct to say the host-inbound traffic mentioned here only concerns itself to traffic that is directed to uranus itself (control plane)?  The security flow status looks like this:

root@uranus# run show security flow status 
  Flow forwarding mode:
    Inet forwarding mode: flow based
    Inet6 forwarding mode: drop
    MPLS forwarding mode: drop
    ISO forwarding mode: drop
    Advanced services data-plane memory mode: Default
  Flow trace status
    Flow tracing status: off

[edit]
root@uranus# 

 As always, any help is appreciated.

Looks fine to me.  Just need to confirm how you have it physically cabled up.  Like this?

 

Traffic (10024) -----> Untrust (vlan.2, fe-0/0/3.0) -----> DNAT to 10.0.102.100 port 22 -----> Test-Zone (vlan.102) -----> ?

 

Looks like you've got a security policy from Untrust-to-Test-Zone so thats good.

 

But what interface is the end device at 10.0.102.100 cabled up to?  Fe-0/0/7.0? Ge-0/0/0.0? Run another test and immediately run the #run show security flow session command to see if you got any hits on policies.  And also run #run show interfaces terse.

 

 

Looks right; just missed the Mac at the end of the connection:

Traffic (10024) -----> Untrust (vlan.2, fe-0/0/3.0) -----> DNAT to 10.0.102.100 port 22 -----> Test-Zone (vlan.102, f3-0/0/7.0) -----> Mac (the target) port 22

I am probulating uranus from 10.0.0.0/24 by doing "nc -v 10.0.0.2 10024". "run show security flow session" is not showing any sessions going on.

root@uranus# run show security flow session    
Total sessions: 0

[edit]
root@uranus#

And here are my interfaces:

root@uranus# run show interfaces terse 
Interface               Admin Link Proto    Local                 Remote
ge-0/0/0                up    up
ge-0/0/0.0              up    up   eth-switch
gr-0/0/0                up    up
ip-0/0/0                up    up
lsq-0/0/0               up    up
lt-0/0/0                up    up
mt-0/0/0                up    up
sp-0/0/0                up    up
sp-0/0/0.0              up    up   inet    
sp-0/0/0.16383          up    up   inet     10.0.0.1            --> 10.0.0.16
                                            10.0.0.6            --> 0/0
                                            128.0.0.1           --> 128.0.1.16
                                            128.0.0.6           --> 0/0
ge-0/0/1                up    down
ge-0/0/1.0              up    down eth-switch
fe-0/0/2                up    down
fe-0/0/2.0              up    down eth-switch
fe-0/0/3                up    up
fe-0/0/3.0              up    up   eth-switch
fe-0/0/4                up    down
fe-0/0/4.0              up    down eth-switch
fe-0/0/5                up    down
fe-0/0/5.0              up    down eth-switch
fe-0/0/6                up    down
fe-0/0/6.0              up    down eth-switch
fe-0/0/7                up    up
fe-0/0/7.0              up    up   eth-switch
fxp2                    up    up
fxp2.0                  up    up   tnp      0x1             
gre                     up    up
ipip                    up    up
irb                     up    up
lo0                     up    up
lo0.16384               up    up   inet     127.0.0.1           --> 0/0
lo0.16385               up    up   inet     10.0.0.1            --> 0/0
                                            10.0.0.16           --> 0/0
                                            128.0.0.1           --> 0/0
                                            128.0.0.4           --> 0/0
                                            128.0.1.16          --> 0/0
lo0.32768               up    up  
lsi                     up    up
mtun                    up    up
pimd                    up    up
pime                    up    up
pp0                     up    up
ppd0                    up    up        
ppe0                    up    up
st0                     up    up
tap                     up    up
vlan                    up    up
vlan.0                  up    down inet     192.168.1.1/24  
vlan.2                  up    up   inet     10.0.0.2/24     
vlan.3                  up    up   inet     192.168.3.2/24  
vlan.102                up    up   inet     10.0.102.1/24   

[edit]
root@uranus#

Well I'm not sure if that test you're running will actually generate a session though.  If you just run an actual SSH connection on port 10024 does it show any sessions?

This time I did ssh -p 10024 10.0.0.2:

OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /home/raub/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.0.0.2 [10.0.0.2] port 10024.
Other than the dns traffic I caught by sheer luck, nothing interesting:
root@uranus# run show security flow session
Session ID: 15053, Policy name: test-to-untrust/6, Timeout: 2, Valid
  In: 10.0.102.100/64152 --> 208.67.222.222/53;udp, If: vlan.102, Pkts: 1, Byte5
  Out: 208.67.222.222/53 --> 10.0.0.2/18815;udp, If: vlan.2, Pkts: 1, Bytes: 81
Total sessions: 1

[edit]
root@uranus# run show security flow session
Total sessions: 0

[edit]
root@uranus#
That said, looking at the flow session, I really wonder if my traffic is being blocked right as it touches vlan.102. In other words, blocked by firewall or something.

Yea at this point I'm not sure what could be blocking it.  You could try just allowing everything on your zone configuration to see if that helps:

 

host-inbound-traffic {
    system-services {
        all;
    }
    protocols {
        all;
    }
}
interfaces {
    vlan.102

 

OR

 

You could run some security flow traceoptions to verify that its even seeing the packet:

 

set security flow traceoptions file flow-log

set security flow traceoptions file files 2

set security flow traceoptions flag basic-datapath

set security flow traceoptions packet-filter inbound source-prefix x.x.x.x/32    (an external ip originating the connection)

set security flow traceoptions packet-filter inbound destination-prefix x.x.x.x/32  (srx's "external" ip)

set security flow traceoptions packet-filter return source-prefix x.x.x.x/32          (10.0.102.100)

set security flow traceoptions packet-filter return destination-prefix x.x.x.x/32  (the external ip orginating the connection
#commit

Attempt a connection then use the following command to view the log file.

>show log flow-log

Also use ">clear log flow-log" to empty the file so you can rid it of old connection attempts and only see new ones.

You'll need to fill in the correct addresses on each filter, but If the traffic doesn't show up in this log, then it might not be getting to the SRX at all.  This will show the flow process/nat rule/security policy/etc, Post the output of the log once you've attempted a connection attempt with the filters in place. 

Thanks for the security flow setup info. So, I set your instructions up for my mess:

set security flow traceoptions file flow-log 
set security flow traceoptions file files 2 
set security flow traceoptions flag basic-datapath 
set security flow traceoptions packet-filter inbound source-prefix 10.0.0.249/32
set security flow traceoptions packet-filter inbound destination-prefix 10.0.0.2/32
set security flow traceoptions packet-filter return source-prefix 10.0.102.100/32
set security flow traceoptions packet-filter return destination-prefix 10.0.0.249/32

And here is what "show log flow-log" gives me back:

Jun 4 13:20:13 uranus clear-log[16803]: logfile cleared
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:<10.0.0.249/53862->10.0.0.2/10024;6> matched filter inbound:
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:packet [60] ipid = 61034, @423f961e
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 14, common flag 0x0, mbuf 0x423f9400, rtbl_idx = 0
Jun  4 13:20:29 13:20:29.032120:CID-0:RT: flow process pak fast ifl 69 in_ifp vlan.2
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  vlan.2:10.0.0.249/53862->10.0.0.2/10024, tcp, flag 2 syn
Jun  4 13:20:29 13:20:29.032120:CID-0:RT: find flow: table 0x489225d8, hash 23362(0xffff), sa 10.0.0.249, da 10.0.0.2, sp 53862, dp 10024, proto 6, tok 7
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  no session found, start first path. in_tunnel - 0, from_cp_flag - 0
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:check self-traffic on vlan.2, in_tunnel 0x0                        
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:retcode: 0x1
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:pak_for_self : proto 6, dst port 10024, action 0x0
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  flow_first_create_session
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  flow_first_in_dst_nat: in <VLAN.2>, out <N> dst_adr 10.0.0.2, sp 53862, dp 10024
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  chose interface vlan.2 as incoming nat if.
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:flow_first_rule_dst_xlate: DST xlate: 10.0.0.2(10024) to 10.0.102.100(22), rule/pool id 1/2.
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 10.0.0.249, x_dst_ip 10.0.102.100, in ifp vlan.2, out ifp N/A sp 53862, dp 10024, ip_proto 6, tos 0
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:Doing DESTINATION addr route-lookup
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  routed (x_dst_ip 10.0.102.100) from untrust (vlan.2 in 0) to vlan.102, Next-hop: 10.0.102.100
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:flow_first_policy_search: policy search from zone untrust-> zone test-zone (0x110,0xd2662728,0x16)
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:Policy lkup: vsys 0 zone(7:untrust) -> zone(10:test-zone) scope:0
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:             10.0.0.249/53862 -> 10.0.102.100/22 proto 6
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:Policy lkup: vsys 0 zone(5:Unknown) -> zone(5:Unknown) scope:0
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:             10.0.0.249/53862 -> 10.0.102.100/22 proto 6
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  app 22, timeout 1800s, curr ageout 20s
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  packet dropped, denied by policy
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  denied by policy default-policy-00(2), dropping pkt
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  packet dropped,  policy deny.
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  flow find session returns error.
Jun  4 13:20:29 13:20:29.032120:CID-0:RT: ----- flow_process_pkt rc 0x7 (fp rc -1)</N></VLAN.2>

From what I can see, here is where it drops the packet:

Jun  4 13:20:29 13:20:29.032120:CID-0:RT:Policy lkup: vsys 0 zone(7:untrust) -> zone(10:test-zone) scope:0
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:             10.0.0.249/53862 -> 10.0.102.100/22 proto 6
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:Policy lkup: vsys 0 zone(5:Unknown) -> zone(5:Unknown) scope:0
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:             10.0.0.249/53862 -> 10.0.102.100/22 proto 6
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  app 22, timeout 1800s, curr ageout 20s
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  packet dropped, denied by policy
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  denied by policy default-policy-00(2), dropping pkt

So, it goes fine until finding this Unknown zone, whatever it is. And that kicks in a default policy. I thought the dropping was being done at the untrust zone, but I guess I was wrong.

I have never seen that before.  I would submit that to JTAC unless someone else wants to chime in, I'm out of tricks. 😞

 

You could always save off the config, factory-default it, or zeroize the device (be careful with that one), upgrade the software to recommended code for your platform and then throw the config back on it and see if it helps.

I wonder if you changed your internal address range to a 172.16.x.x/24 network if that would make things different.  Maybe it thinks your wan and lan ip's are overlapping address spaces on the 10.0.0.0/8.  If you did change it just to test this you have to remember to change your address book entries and dnat policies and dhcp scope with new static binding.  I dunno, I'm grasping now.

I do see your point, and must say I would be rather annoyed if it is trying to use 10.0.0.0/8; after all the dhcp server feeding it claims the netmask is /24:

root@uranus# run show route

inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 1w2d 12:43:46
                    > to 10.0.0.1 via vlan.2
10.0.0.0/24        *[Direct/0] 1w2d 13:10:24
                    > via vlan.2
10.0.0.2/32        *[Local/0] 1w5d 08:32:44
                      Local via vlan.2
10.0.102.0/24      *[Direct/0] 1w4d 08:28:11
                    > via vlan.102
10.0.102.1/32      *[Local/0] 1w4d 12:40:06
                      Local via vlan.102
192.168.1.1/32     *[Local/0] 1w5d 08:32:44
                      Reject
192.168.3.0/24     *[Direct/0] 1w2d 18:18:36
                    > via vlan.3
192.168.3.2/32     *[Local/0] 1w5d 08:32:43
                      Local via vlan.3

[edit]
root@uranus# 

So, before I go play with that, let's do some more looking at the log. Last night I found http://kb.juniper.net/InfoCenter/index?page=content&id=KB21757 and would like you to take a look at the item 3 under the Example Traceoption ouptut for Destination NAT session. It sure looks like my own issue, doesn't it? According to it, the packet has been dropped because the policy was made for the wrong destination, in their case 1.1.1.1 instead of 192.168.5.1. Looking at the rest of the page, 1.1.1.1 seems to represent the external router IP while 192.168.5.1 the IP for some internal dishwasher. So, if we apply that to my own logs,

1. Jun 4 13:20:29 13:20:29.032120:CID-0:RT:flow_first_rule_dst_xlate: DST xlate: 10.0.0.2(10024) to 10.0.102.100(22), rule/pool id 1/2.
2. Jun 4 13:20:29 13:20:29.032120:CID-0:RT:Policy lkup: vsys 0 zone(7:untrust) -> zone(10:test-zone) scope:0
3. Jun 4 13:20:29 13:20:29.032120:CID-0:RT:Policy lkup: vsys 0 zone(5:Unknown) -> zone(5:Unknown) scope:0
4. Jun 4 13:20:29 13:20:29.032120:CID-0:RT: packet dropped, denied by policy
5. Jun 4 13:20:29 13:20:29.032120:CID-0:RT: packet dropped, policy deny.

It would imply the policy had been dropped because the policy was made for destination IP 10.0.0.2. Now, if we look at my destination nat rule,

root@uranus# show security nat destination                       
pool ssh_pork_pool {
    address 10.0.102.100/32 port 22;
}
rule-set SSH-UNTRUST-TO-TRUST {
    from zone untrust;
    rule DEST-NAT {
        match {
            destination-address 10.0.0.2/32;
            destination-port 10024;
        }
        then {
            destination-nat pool ssh_pork_pool;
        }
    }
}

[edit]
root@uranus#  
I have to ask what do they mean by the destination IP? The destination-address? But, I thought that is the address for the router interface we are connecting to.

Yes, with DNAT the device is examining the destination-ip address field in the packet, hence the match criteria in the DNAT rule.  And in your setup 10.0.0.2 is the "external" ip you would be connecting to from the "outside".  Whats odd is that its showing the correct zone-to-zone context first, and then showing the "unknown" zone issue in th log.

 

1. Jun 4 13:20:29 13:20:29.032120:CID-0:RTolicy lkup: vsys 0 zone(7:untrust) -> zone(10:test-zone) scope:0
2. Jun 4 13:20:29 13:20:29.032120:CID-0:RTolicy lkup: vsys 0 zone(5:Unknown) -> zone(5:Unknown) scope:0

I don't know why its showing this.

 

Just for grins, change your security zone setup back to this:

 

security-zone test-zone {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                vlan.102

Remove everything under vlan.102 so it looks like mine here.

I did set that test-zone as yours but still no dice. Now, here is something that is bothering me: if you remember from the flow output we have

Jun 4 13:20:29 13:20:29.032120:CID-0:RT:policy lkup: vsys 0 zone(5:Unknown) -> zone(5:Unknown) scope:0

What is that number 5 in there? I ask because in

root@uranus# run show security policies
Default policy: deny-all
From zone: trust, To zone: untrust
  Policy: trust-to-untrust, State: enabled, Index: 4, Scope Policy: 0, Sequence number 1
    Source addresses: any
    Destination addresses: any
    Applications: any
    Action: permit
From zone: untrust, To zone: test-zone
  Policy: WAN-TO-TEST, State: enabled, Index: 5, Scope Policy: 0, Sequence number 1
    Source addresses: any
    Destination addresses: oldpork
    Applications: ssh_strangepork
    Action: permit
From zone: test-zone, To zone: untrust
  Policy: test-to-untrust, State: enabled, Index: 6, Scope Policy: 0, Sequence number 1
    Source addresses: any
    Destination addresses: any
    Applications: any
    Action: permit

[edit]
root@uranus# 

We have these indexes associated with the different policies, being 5 WAN-TO-TEST. Of course what I said does not make sense because of a previous entry in the flow thingie,

Jun 4 13:20:29 13:20:29.032120:CID-0:RT:Policy lkup: vsys 0 zone(7:untrust) -> zone(10:test-zone) scope:

Also,

root@uranus# run show security match-policies source-ip 10.0.0.2 destination-ip 192.168.102.100 source-port 10024 result-count 16 destination-port 22 from-zone untrust to-zone test-zone protocol tcp                     
Policy: Default-Policy, action-type: deny-all, State: enabled, Index: 2
  Sequence number: 2

[edit]
root@uranus#

Does that mean my policy is not being seen at all?

Hey Raub,

I think I see the problem - from the debug it appears that the destination NAT is working correctly, as shown in the flow:

 

Jun  4 13:20:29 13:20:29.032120:CID-0:RT:flow_first_rule_dst_xlate: DST xlate: 10.0.0.2(10024) to 10.0.102.100(22), rule/pool id 1/2.

 

However it appears that the policy lookup is failing as you have described:

 

Jun  4 13:20:29 13:20:29.032120:CID-0:RT:Policy lkup: vsys 0 zone(5:Unknown) -> zone(5:Unknown) scope:0
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:             10.0.0.249/53862 -> 10.0.102.100/22 proto 6
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  app 22, timeout 1800s, curr ageout 20s
Jun  4 13:20:29 13:20:29.032120:CID-0:RT:  packet dropped, denied by policy

 

If you take note the destination NAT is pointing to destination port 22, while the security policy is only allowing port 10024 to the host. Since the application does not match the destination port, then the policy lookup fails and the packet is dropped. Destination NAT is performed before policy lookup, so if you set the application to match junos-ssh it should work for you.

 

 

Hope that helps!

I agree with Dark.....your application port post-dnat, would just need to be junos-ssh (22). 

It was indeed! For some reason I thought I had to be listening on port 1002. i.e. Destination NAT was performed after policy lookup. I stand corrected. Thanks for all the help! I always like when I learn something new

If you are not doing this already.

Use Proxy-Arp to bring the IP address and then dnat for port 22 should work.