SRX

This message was posted by a user wishing to remain anonymous

We are trying to determine how we can record or log specific routing/forwarding events where our SRX device is configured in flow-mode and performs source NAT for our inside network and translates these address pools to a public address configured on a local interface which links to our ISP for traffic leaving our site.

We have a filter applied on our inside interface which matches traffic destined to certain IP blocks and one term is configured to mark this for packet-mode.

This seems counter intuitive given that Juniper confirms that packet-mode is not supported under source NAT and so in attempting to confirm this on the SRX, we have tried using the operational command:

show security show security flow session nat source-prefix X.X.X.X

where X.X.X.X is a known internal IP address that we know is covered by NAT because of the above command providing output of the sessions held by the host and for which NAT has been applied.

However, given that we have those terms where we match specific traffic to use packet-mode, where does this traffic go?

We don't have particular routing policy for the destination targets and they simply follow the default route towards our ISP. However, without NAT, these shouldn't go anywhere.

How can we have the SRX log these particular events where the filter allows the traffic, puts in packet-mode, and (we assume) is not routing it out? Is there such a log we can generate or look at?

We did think about using filter term counters which did let us see that packets matching the term criteria entering the inside interface on the firewall but a similar term (using different filter) set on the outside interface going to our ISP with another counter did not get any hits. We are assuming then that this is due to packet-mode causing these packets to not get routed out due to missing crucial NAT piece (because we use source NAT).

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

The absence of source NAT should not preclude routing. Without NAT, packets would just go out with their internal addresses visible which the ISP may or may not discard.

Packet-mode is bypassing the flow module which is responsible for, among other things, performing NAT, that's why source NAT is unsupported for packet-mode traffic, but you should still have that traffic forwarded.

I was going to suggest an output filter counter as well. Interesting. Do you mind providing configuration snippets (edited for privacy), at least for the filters?

------------------------------
Nikolay Semov
------------------------------

This message was posted by a user wishing to remain anonymous

Thank you for clarifying on the routing part. I wasn't very sure about how this was all working under the hood.

While I work on getting the config snippets, I did want to ask first if packets from the inside network flowing through the SRX and out an interface with a public IP address will work? Reading again what's been mentioned so far, it sounds like this is what could be happening. I always thought they called them non-routable addresses because they could not be forwarded beyond an external-facing interface.

For example:

192.168.0.X/24 <----(      R1      )---> 13.3.2.1 ---------- 13.3.2.2 <--- (         ISP          )

I never knew about the specifics and always assumed something built-in would just discard it but assuming something like the above, can something with source 192.168.0.1 without anything blocking it even on R1's policies, can it be sent out to the ISP link?

We don't have any special config or setup with our ISP that would make me think our ISP would even accept the traffic. It's pretty much a business Internet circuit.

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

Original Message:
Sent: 09-05-2025 21:33
From: Nikolay Semov
Subject: How to log discard event for packet-mode where source NAT is enabled?

The absence of source NAT should not preclude routing. Without NAT, packets would just go out with their internal addresses visible which the ISP may or may not discard.

Packet-mode is bypassing the flow module which is responsible for, among other things, performing NAT, that's why source NAT is unsupported for packet-mode traffic, but you should still have that traffic forwarded.

I was going to suggest an output filter counter as well. Interesting. Do you mind providing configuration snippets (edited for privacy), at least for the filters?

------------------------------
Nikolay Semov
------------------------------

This message was posted by a user wishing to remain anonymous

We basically have something like this on the inside interface applied filter:

from {
    destination-address {
        X.X.X.X/28;
        Y.Y.Y.Y/19;
        X.X.Y.Y/12;
    }
    protocol udp;
    destination-port [ 3 4 7 8 ];
}
then {
    packet-mode;
    forwarding-class efc;
}

... and then on the outside interface connecting to the ISP/Internet has a similar filter/term matching the source with the same destination IPs and similarly marks the traffic accordingly. Also these prefixes in the terms are public endpoints. We try to apply some QoS for latency sensitive applications used by our users.

Both filters have an explicit allow all term and neither filter is configured to block any traffic. They pretty much serve as MF classifiers for CoS.

Do firewalls in this case really still let the packet leave the outside facing interface towards the ISP even though the packet hasn't gone through NAT?

I always thought the device would have something built-in where it's able to route it but decides not to because the direct next-hop is also a public endpoint.

If it is true that the packets we are marking to use packet-mode are still leaving our site, my guess would be that our ISP is likely dropping them. AFAIK, we do not have any special agreement or arrangement for them to take such traffic (we don't have something like MPLS) and even then, all I can say is that we only have common fiber business Internet circuit. Our public facing interface on our edge firewall is only peered to our ISP which I know only has a public address. I don't think it would take traffic from our site that has source address in RFC1918 range.

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

Original Message:
Sent: 09-05-2025 21:33
From: Nikolay Semov
Subject: How to log discard event for packet-mode where source NAT is enabled?

The absence of source NAT should not preclude routing. Without NAT, packets would just go out with their internal addresses visible which the ISP may or may not discard.

Packet-mode is bypassing the flow module which is responsible for, among other things, performing NAT, that's why source NAT is unsupported for packet-mode traffic, but you should still have that traffic forwarded.

I was going to suggest an output filter counter as well. Interesting. Do you mind providing configuration snippets (edited for privacy), at least for the filters?

------------------------------
Nikolay Semov
------------------------------

Your ISP (or some other intermediary ISP) is very likely to drop the traffic.

And even if your traffic does reach the destination, the return traffic from X.X.X.X to 192.168.0.X is definitely for sure not coming back to you. Though, I suppose, since you're sending UDP packets, it's conceivable that you could have some extremely specific application that does not need return traffic.

------------------------------
Nikolay Semov
------------------------------

Original Message:
Sent: 09-09-2025 08:56
From: Anonymous
Subject: How to log discard event for packet-mode where source NAT is enabled?

This message was posted by a user wishing to remain anonymous

We basically have something like this on the inside interface applied filter:

from {
    destination-address {
        X.X.X.X/28;
        Y.Y.Y.Y/19;
        X.X.Y.Y/12;
    }
    protocol udp;
    destination-port [ 3 4 7 8 ];
}
then {
    packet-mode;
    forwarding-class efc;
}

... and then on the outside interface connecting to the ISP/Internet has a similar filter/term matching the source with the same destination IPs and similarly marks the traffic accordingly. Also these prefixes in the terms are public endpoints. We try to apply some QoS for latency sensitive applications used by our users.

Both filters have an explicit allow all term and neither filter is configured to block any traffic. They pretty much serve as MF classifiers for CoS.

Do firewalls in this case really still let the packet leave the outside facing interface towards the ISP even though the packet hasn't gone through NAT?

I always thought the device would have something built-in where it's able to route it but decides not to because the direct next-hop is also a public endpoint.

If it is true that the packets we are marking to use packet-mode are still leaving our site, my guess would be that our ISP is likely dropping them. AFAIK, we do not have any special agreement or arrangement for them to take such traffic (we don't have something like MPLS) and even then, all I can say is that we only have common fiber business Internet circuit. Our public facing interface on our edge firewall is only peered to our ISP which I know only has a public address. I don't think it would take traffic from our site that has source address in RFC1918 range.

This message was posted by a user wishing to remain anonymous

Instead of using firewall rules, I would create a new source nat rule for your trusted zone where source-nat will be disabled for a particular IP range, this will keep you in the flow session, and you use the logging capabilities associated with flow sessions and zone security policies.

The traffic really doesn't go anywhere because there's no NAT in packet-mode, and the best way to prove it is by combining filter logging with traceoptions.

------------------------------
ALEXANDRE GALVAO
------------------------------