SRX Services Gateway
SRX Services Gateway

SRX 1500 Packet trace not working as expected

[ Edited ]
‎10-30-2017 07:55 AM

Hi,

 

I have the topology as showing here https://imgur.com/a/xB09y .  I need to prove to my supplier which I connect through via reth2.0 that traffic is leaving my device correctly. To do this I want to do a packet capture and send it to them. Using the below settings a pcap is created but it doesnt contain any traffic for reth2.0 which should be 10.x.x.x. Instead it seems to contain traffic from reth1.0 mainly broadcast from a server with IP of 192.168.1.3. FYI far end sip server is on 100 network incase you think I've made a typo.

 

Some help would be great I've been on this a while Smiley Sad

 

edit forwarding-options packet-capture
set file filename mytrace
set file size 5m
set maximum-capture-size 1500

set firewall filter PCAP term 1 then sample
set firewall filter PCAP term 1 then accept

set firewall filter PCAP term 2 then sample
set firewall filter PCAP term 2 then accept
set firewall filter PCAP term allow-all-else then accept

set interfaces reth2 unit 0 family inet filter output PCAP
set interfaces reth2 unit 0 family inet filter input PCAP

commit

 

I have tried the same filter but on reth1 and source / destination completed and I do see traffic from 192.168.1.100 > 100.0.55.30. But really I need to see a pcap showing the traffic leaving reth2 as thats the interface which my provider is connected too.

 

If I so show security flow session destination-prefix 100.0.55.30 I get, where to me the 0 Pkts seems wrong?:

 

Session ID: 914732, Policy name: inside-zone-outbound/17, State: Backup, Timeout: 1808, Valid
In: 192.168.1.100/5060 --> 100.0.55.30/5060;udp, Conn Tag: 0x0, If: reth1.0, Pkts: 0, Bytes: 0
Out: 100.0.55.30/5060 --> 10.0.5.100/5060;udp, Conn Tag: 0x0, If: reth2.0, Pkts: 0, Bytes: 0

8 REPLIES 8
SRX Services Gateway

Re: SRX 1500 Packet trace not working as expected

‎10-30-2017 01:53 PM

State: Backup from show security flow sessions output means it's form secondary node. As secondery node doesn't pass traffic counters show 0. It's ok.

Packet capture configuration looks fine. What Junos version do you have? I can search if there are any matching bugs.

Regards, Wojtek

SRX Services Gateway

Re: SRX 1500 Packet trace not working as expected

‎10-30-2017 11:12 PM
Are you getting any traffic for output of
"run monitor traffic interface reth2"?

*************************************
HTH.
Accept this as solution if it resolved your issue.
Kudos would be appreciated too.
SRX Services Gateway

Re: SRX 1500 Packet trace not working as expected

‎10-31-2017 03:24 AM

Strange why its showing the backup then?

 

JUNOS 15.1X49-D60.7 built 2016-09-13 23:16:14 UTC

SRX Services Gateway

Re: SRX 1500 Packet trace not working as expected

[ Edited ]
‎10-31-2017 03:33 AM

When I run 'monitor traffic interface reth2', I don't see the traffic I'm sending but there is stuff going on like below. The strange thing when I run the same command at the site where its all fine I dont see any traffic at all:

 

10:22:16.694642 In STP 802.1d, Config, Flags [none], bridge-id 8001.bc:c4:93:70:d5:00.8018, length 43
10:22:18.694993 In STP 802.1d, Config, Flags [none], bridge-id 8001.bc:c4:93:70:d5:00.8017, length 43
10:22:18.695122 In STP 802.1d, Config, Flags [none], bridge-id 8001.bc:c4:93:70:d5:00.8018, length 43
10:22:20.697309 In STP 802.1d, Config, Flags [none], bridge-id 8001.bc:c4:93:70:d5:00.8017, length 43
10:22:20.697437 In STP 802.1d, Config, Flags [none], bridge-id 8001.bc:c4:93:70:d5:00.8018, length 43
10:22:21.528845 Out arp who-has 10.0.5.2 tell 10.0.5.1
10:22:21.534881 In arp who-has 10.0.5.2 tell 10.0.5.1
10:22:22.700148 In STP 802.1d, Config, Flags [none], bridge-id 8001.bc:c4:93:70:d5:00.8017, length 43
10:22:22.700295 In STP 802.1d, Config, Flags [none], bridge-id 8001.bc:c4:93:70:d5:00.8018, length 43
10:22:24.704356 In STP 802.1d, Config, Flags [none], bridge-id 8001.bc:c4:93:70:d5:00.8017, length 43
10:22:24.704493 In STP 802.1d, Config, Flags [none], bridge-id 8001.bc:c4:93:70:d5:00.8018, length 43
10:22:26.705979 In STP 802.1d, Config, Flags [none], bridge-id 8001.bc:c4:93:70:d5:00.8017, length 43
10:22:26.706101 In STP 802.1d, Config, Flags [none], bridge-id 8001.bc:c4:93:70:d5:00.8018, length 43

 

10.0.5.2 = my reth2.0 IP

10.0.5.1 = Gateway IP on supplier side

 

Also just saw this:

Reverse lookup for 10.0.5.1 failed (check DNS reachability).
Other reverse lookup failures will not be reported.

SRX Services Gateway

Re: SRX 1500 Packet trace not working as expected

‎10-31-2017 06:28 AM
First I would like to check if your end to end communication is working or not..

Can you pl confirm it?

Also, if you are creating trace-options under edit security flow with matching source & destination prefixes, do u get the traffic?

*************************************
HTH.
Accept this as solution if it resolved your issue.
Kudos would be appreciated too.
SRX Services Gateway

Re: SRX 1500 Packet trace not working as expected

‎11-01-2017 03:01 AM

What do you mean by end to end? As it not working I'm not sure what you are asking....

SRX Services Gateway

Re: SRX 1500 Packet trace not working as expected

‎11-01-2017 07:51 AM

monitor traffic interface is showing traffic destined to/originated by routing engine. As you are interested in transit traffic it's not a proper tool.

 

optput of show security flow session should display session information for both nodes. On secondary node it should have backup state unless you have asymmetric traffiz (Z-mode).

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

 

As milind.mistry@visnet.in suggested you may try to enable trace-options for this flow

set security flow traceoptions file sip_trace
set security flow traceoptions flag basic-datapath
set security flow traceoptions packet-filter 1 destination-prefix 100.0.55.30/32
set security flow traceoptions packet-filter 1 source-prefix 192.168.1.100/32
set security flow traceoptions packet-filter 2 destination-prefix 192.168.1.100/32
set security flow traceoptions packet-filter 2 source-prefix 100.0.55.30/32

Generate some traffic and then see the trace using

show log sip_trace

 

Regards, Wojtek

 

 

Highlighted
SRX Services Gateway
Solution
Accepted by topic author VOIPBunny
‎06-25-2018 01:13 AM

Re: SRX 1500 Packet trace not working as expected

‎11-06-2017 03:59 AM

I have tried to validate this functionality on SRX1500 and can confirm that it works as expected and described in https://kb.juniper.net/InfoCenter/index?page=content&id=KB11709.

 

Enviroment:

SRX1500 with destination nat on 1.2.3.4:2222 towards 172.30.104.1:22 with source-nat on ge-0/0/11.104.

concept.png 

config snippets:

user@srx1500-nfr> show configuration security nat destination
pool test-inside {
    address 172.30.104.1/32 port 22;
}
rule-set WAN {
    from zone untrust;
    rule test {
        match {
            destination-address 1.2.3.4/32;
            destination-port {
                2222;
            }
        }
        then {
            destination-nat {
                pool {
                    test-inside;
                }
            }
        }
    }
}
user@srx1500-nfr> show configuration security nat source
pool src-hide {
    address {
        172.30.104.254/32;
    }
}
rule-set test-src {
    from zone untrust;
    to zone test;
    rule src-tux {
        match {
            source-address 4.3.2.1/32;
        }
        then {
            source-nat {
                pool {
                    src-hide;
                }
            }
        }
    }
}
user@srx1500-nfr> show configuration security policies from-zone untrust to-zone test
policy test {
    match {
        source-address external-host;
        destination-address test-inside;
        application junos-ssh;
    }
    then {
        permit;
        log {
            session-init;
            session-close;
        }
    }
}
user@srx1500-nfr> show configuration interfaces

ge-0/0/1 {
    unit 0 {
        family inet {
            filter {
                input PCAP;
                output PCAP;
            }
            address 1.2.3.4/27;
        }
    }
}
ge-0/0/11 {
    vlan-tagging;
    unit 104 {
        vlan-id 104;
        family inet {
            filter {
                input PCAP;
                output PCAP;
            }
            address 172.30.104.254/24;
        }
    }
}
user@srx1500-nfr> show configuration firewall
filter PCAP {
    term 1 {
        from {
            source-address {
                4.3.2.1/32;
            }
            destination-address {
                1.2.3.4/32;
            }
        }
        then {
            sample;
            accept;
        }
    }
    term 2 {
        from {
            source-address {
                1.2.3.4/32;
            }
            destination-address {
                4.3.2.1/32;
            }
        }
        then {
            sample;
            accept;
        }
    }
    term 3 {
        from {
            source-address {
                172.30.104.254/32;
            }
            destination-address {
                172.30.104.1/32;
            }
        }
        then {
            sample;
            accept;
        }
    }
    term 4 {
        from {
            source-address {
                172.30.104.1/32;
            }
            destination-address {
                172.30.104.254/32;
            }
        }
        then {
            sample;
            accept;
        }
    }
    term allow-all-else {
        then accept;
    }
}
user@srx1500-nfr> show configuration forwarding-options
packet-capture {
    file filename pcapdump files 5 size 5m;
    maximum-capture-size 1500;
}

Traffic passes correctly when testing from the outside, flow session is show and pcapdump files are generated:

 

ssh -p 2222 root@1.2.3.4
Password:
Last login: Mon Nov  6 11:06:22 2017 from 172.30.104.254
--- JUNOS 15.1X49-D100.6 built 2017-06-28 07:33:31 UTC
root@vsrx-test%

user@srx1500-nfr> show security flow session
Session ID: 901793, Policy name: test/6, Timeout: 1800, Valid
 In: 4.3.2.1/33090 --> 1.2.3.4/2222;tcp, Conn Tag: 0x0, If: ge-0/0/1.0, Pkts: 93, Bytes: 7697,
 Out: 172.30.104.1/22 --> 172.30.104.254/28608;tcp, Conn Tag: 0x0, If: ge-0/0/11.104, Pkts: 165, Bytes: 17501,
Total sessions: 1

jh@srx1500-nfr> file list /var/tmp/pcapdump*
/var/tmp/pcapdump.ge-0.0.1
/var/tmp/pcapdump.ge-0.0.11

and content from tne internal interface is also shown correct ly in the dump file:

root@srx1500-nfr%  tcpdump -ttttnr /var/tmp/pcapdump.ge-0.0.11 | grep 28608
17. 375924 Out IP 172.30.104.254.28608 > 172.30.104.1.22: S 3112655166:3112655166(0) win 65535 <mss 1460,nop,wscale 6,sackOK,timestamp 2729284302 0>
000008  In IP 172.30.104.1.22 > 172.30.104.254.28608: S 1009170727:1009170727(0) ack 3112655167 win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 372119 2729284302,sackOK,eol>
000016 Out IP 172.30.104.254.28608 > 172.30.104.1.22: . ack 1 win 1040 <nop,nop,timestamp 2729284308 372119>
000010 Out IP 172.30.104.254.28608 > 172.30.104.1.22: P 1:50(49) ack 1 win 1040 <nop,nop,timestamp 2729284311 372119>
000005  In IP 172.30.104.1.22 > 172.30.104.254.28608: P 1:22(21) ack 50 win 33279 <nop,nop,timestamp 372123 2729284311>
000034  In IP truncated-ip - 18 bytes missing! 172.30.104.1.22 > 172.30.104.254.28608: . 22:1470(1448) ack 50 win 33304 <nop,nop,timestamp 372123 2729284311>
000043 Out IP 172.30.104.254.28608 > 172.30.104.1.22: . ack 1470 win 1018 <nop,nop,timestamp 2729284329 372123>
000005  In IP 172.30.104.1.22 > 172.30.104.254.28608: P 1470:1670(200) ack 50 win 33304 <nop,nop,timestamp 372124 2729284329>
000042 Out IP truncated-ip - 18 bytes missing! 172.30.104.254.28608 > 172.30.104.1.22: . 50:1498(1448) ack 1470 win 1018 <nop,nop,timestamp 2729284331 372123>
025621 Out IP 172.30.104.254.28608 > 172.30.104.1.22: P 1498:1922(424) ack 1470 win 1018 <nop,nop,timestamp 2729284331 372123>
000006  In IP 172.30.104.1.22 > 172.30.104.254.28608: . ack 1922 win 32368 <nop,nop,timestamp 372124 2729284331>
000023 Out IP 172.30.104.254.28608 > 172.30.104.1.22: P 1922:1970(48) ack 1670 win 1040 <nop,nop,timestamp 2729284345 372124>
128507  In IP 172.30.104.1.22 > 172.30.104.254.28608: P 1670:1950(280) ack 1970 win 33304 <nop,nop,timestamp 372130 2729284345>

So. You need to ensure you are looking at the active node for your RG1 and ensure you are dumping traffic for the right IPS (but as you have "any" it shouldn't been the issue. Hope this walkthrough helps.


--
Best regards,

Jonas Hauge Jensen
Systems Engineer, SEC DATACOM A/S (Denmark)