SRX

Hello
Maybe someone can help with my problem. I have srx cluster with firewall filter rule on engress interface.
Also i have one subnet 192.168.2.0/24 behind the srx  and there was source NAT for internet access. It was working until i add firewall filter.

I cant find any instrucrions or examples for allow source nat through firewall filter.  Have you got any idea ?

Filter example

term icmp-request-reply {
from {
protocol icmp;
}
then {
packet-mode;
accept;
}
}
term well-known-ports {
from {
protocol tcp;
destination-port [ 8443 http https 444 ];
}
then {
packet-mode;
accept;
}
}
term well-known-ports-reply {
from {
protocol tcp;
source-port [ 8443 http https 444 ];
}
then {
packet-mode;
accept;
}
}
term service-ike {
from {
protocol udp;
port 500;
}
then accept;
}
term service-esp {
from {
protocol esp;
}
then accept;

Source nat 

source {
rule-set KE-internet {
from zone Extern;
to zone untrust;
rule KE-1 {
match {
source-address-name KE;
destination-address 0.0.0.0/0;
}
then {
source-nat {
interface;
}
}
}
}

Hello,

---

@alex.a.sobolev77 wrote:

Hello
Maybe someone can help with my problem. I have srx cluster with firewall filter rule on engress interface.
Also i have one subnet 192.168.2.0/24 behind the srx  and there was source NAT for internet access. It was working until i add firewall filter.

 

---

I believe Your real problem statement is different : "my internet access for TCP ports 80, 443, 444, 8443 was working before I added FW filter".

---

@alex.a.sobolev77 wrote:

 

I cant find any instrucrions or examples for allow source nat through firewall filter.  Have you got any idea ?

---

Yes of course.

Output interface filter is executed after source NAT.

Input interface filter is executed before destination NAT.

But I believe Your real problem is not the filter match conditions but "then packet-mode" action inside it.

---

@alex.a.sobolev77 wrote:

term icmp-request-reply {
from {
protocol icmp;
}
then {
packet-mode;
accept;
}
}
term well-known-ports {
from {
protocol tcp;
destination-port [ 8443 http https 444 ];
}
then {
packet-mode;
accept;
}
}
term well-known-ports-reply {
from {
protocol tcp;
source-port [ 8443 http https 444 ];
}
then {
packet-mode;
accept;
}
}

---

 Adding "then packet-mode" makes the matching packet invisible to the flow module. So, it Your c2s TCP SYN with dst.port 80 is handled statefully by flow module, but corresponding s2c TCP SYN-ACK with src.port 80 bypasses flow module because of "then packet-mode" action, then flow module times the session out after ${open-timeout} seconds and any subsequent c2s packets that are handled statefully are dropped.
AFAIK, You have to either use "packet-mode" bidirectionally in input interface filters, or don't use "packet-mode" at all. Using "packet-mode" unidirectionally is prone to problems like this.

Hope this makes sense.

HTH

Thx

Alex 

Thank you. Packed-mode is a reason of the problem.