SRX

Hi everyone,

We want to install a squid proxy (transparent mode). But first we need it to work only for people in a specific subnet.

We have an SRX240h with junos 12.1X44.D40.2. 

Proxy is on reth5.0 (ip 192.168.22.1)

The source subnet is in reth2.13 (ip 192.168.13.0/24)

We've implemented FBF on reth2.13 to identify 80 & 443 packets, and redirect them into the PROXY forwarding RI.

Initially, the reth2.13 and reth5.0 are in the master RI inet.0

Here's the configuration of the RI "PROXY", the filter "proxy" and the interfaces reth2.13 & reth5.0:

set routing-instances PROXY instance-type forwarding
set routing-instances PROXY routing-options static route 0.0.0.0/0 next-hop 192.168.22.1

******

set firewall family inet filter proxy-squid term t1 from source-address 192.168.13.0/24
set firewall family inet filter proxy-squid term t1 from destination-address 0.0.0.0/0
set firewall family inet filter proxy-squid term t1 from protocol tcp
set firewall family inet filter proxy-squid term t1 from destination-port http
set firewall family inet filter proxy-squid term t1 from destination-port https
set firewall family inet filter proxy-squid term t1 then count redirected
set firewall family inet filter proxy-squid term t1 then routing-instance PROXY
set firewall family inet filter proxy-squid term default then accept

******

set interfaces reth2 unit 13 vlan-id 13
set interfaces reth2 unit 13 family inet filter input proxy-squid
set interfaces reth2 unit 13 family inet address 192.168.13.254/24

set interfaces reth5 unit 0 family inet address 192.168.22.254/24

******

Question 1:

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

Do we really need in this case another routing informations in the forwarding RI PROXY besides the default route that point out the proxy (knowing that the proxy is directly connected to reth5.0)?

I've read in this very Forum 2 experts with differents statements :

the 1st:

"Absense of interfaces in forwarding RI makes them unidirectional, i.e. only client->server traffic can pass forwarding RI whereas server->client passes inet.0, and both use same interface.

This makes forwarding RI useful for certain applications at no extra cost of creating rib-groups/instance-import to leak return routes. HTTP header enrichment and WAN acceleration (now EOLed) come to mind as quick examples."

the 2nd:

"No. If using instance-type forwarding, you must use rib-groups, instance-import to import information into the routing table, so that next-hop can be resolved."

Question 2:

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

We've been asked to ensure that the packets that arrive to the proxy must hit it on non standard ports.

Packets with destination-port 80 must arrive to the proxy with destination-port 3128 (for exemple) and those with 443 must arrive with 3129 (for exemple).

How can we perform this on the SRX?

I've tried NAT destination playing only with the destination-ports, but commit check failed 😞

set security nat destination pool 80to3128 address port 3128

set security nat destination rule-set to_PROXY from interface reth2.13
set security nat destination rule-set to_PROXY rule PROXY80 match destination-address 0.0.0.0/32
set security nat destination rule-set to_PROXY rule PROXY80 match destination-port 80
set security nat destination rule-set to_PROXY rule PROXY80 then destination-nat pool 80to3128

Thanks in advance for your swift help 🙂

Hi,

1 - Yes you will need to copy the interface with a rib-group into the PROXY RI as the default route is unable to resolve the next-hop for 192.168.22.1. 

2 - Seems like an odd use case as you will need to do another translation back to 80/443 to reach the host on the internet. 

The destination use cases are;

many to many

- dnat with all ports 

- dnat with pat

one to many 

- dnat ip-a port 80 to ip-b port 8080

- dnat ip-c port 443 to ip-d port 8081

In all cases the ip address is mandatory, in your use case the destination IP address must remain unchanged. 

Tim

Hi Tim,

Thank you for your swift response.

Regarding Question1: i was thinking that the problem will be about the return paths (respone of the Proxy to the host), as the proxy is directly connected to the interface reth5.0.

Actually, we've implemented the filter with an instance-import of the master, and we're seeing the packets arriving to the proxy. 

show configuration routing-instances PROXY | display set    
set routing-instances PROXY instance-type forwarding
set routing-instances PROXY routing-options static route 0.0.0.0/0 next-hop 192.168.22.1
set routing-instances PROXY routing-options instance-import From_INET0_to_PROXY

ylazreq@FW_Node0# run show configuration policy-options policy-statement From_INET0_to_PROXY | display set 
set policy-options policy-statement From_INET0_to_PROXY term 1 from instance master
set policy-options policy-statement From_INET0_to_PROXY term 1 from interface reth5.0
set policy-options policy-statement From_INET0_to_PROXY term 1 then accept
set policy-options policy-statement From_INET0_to_PROXY term 2 then reject

 Today, we'll do the test by removing the instance-import, and see if the packets will arrive or not, and of course i will inform you 🙂

Regarding Question 2: i agree with you. It's an odd use case of destination PAT 🙂 They really want the proxy to listen to packets in a non-standard port., and they asked us to do the "trick" on the FW !!!

But how can achieve this asked task?

I've seen quickly on the web something called "Port forwarding". I've seen that the commands are not available on our SRX (in our actual OS). could it be a solution?

Thanks again for your help 🙂

Hi,

instance-import or rib copy will produce the same result - copy routes 🙂

Let me confirm what you are trying to do with the PAT.

Client 1.1.1.1 connects to www.google.com:80

SRX performs FBF and forwards packet to squid

(PAT - The packet should now be 1.1.1.1 -> www.google.com:3128) ?

Squid gets packet on 3128 then translates the port back to 80 and sends to www.google.com:80 ?

I do not see a need to make it more complicated then it already is. The users can't see the squid anyway so it should not matter that it is on standard web ports.

Tim

Thank you Tim,

Do you confirm that even "directly connected" subnets, need to be learned by the RIB of the forwarding RI by another "external" mecanism?

And yes, i completly share your point of view 🙂 I confirm that you've got the point exactly.

So how can we do it? 🙂

Hi,

Yes with FBF the route that is copied is always "direct" this is for NH reachability. The default route must know where to forward the packets.

You can't change just the port, you must change the IP or IP and port for destination NAT.

Tim

Tim,

Thanks again for your response.

Regarding Question 1:

We've implemented the FBF without the instance-import, and as expected the proxy didn't receive anything from the host.

We've conclude that, as you said, the route importation is mandatory to tell the forwarding RI were to find the proxy (even if it's directly connected).

I've understood also that both expert's responses are complemantary 🙂

1st expert:

" Absense of interfaces in forwarding RI makes them unidirectional, i.e. only client->server traffic can pass forwarding RI whereas server->client passes inet.0, and both use same interface.

This makes forwarding RI useful for certain applications at no extra cost of creating rib-groups/instance-import to leak return routes."

----> The use of rib-groups/instance-import concerns only the 1st direction (Host to Proxy), because only this communication is happening in the forwarding VR. 

----> the return traffic goes through the master RI, so no need to re-learn in the forwarding RI what's known in inet.0 🙂

2nd expert:

" No. If using instance-type forwarding, you must use rib-groups, instance-import to import information into the routing table, so that next-hop can be resolved."
----> The forwrding RI's RIB is empty. Even the directly connected subnets aren't automatically inserted in it !!! So the next-hop is unknown, that's what the route import is for.

Could you confirm my statement?

Regarding Question 2:

I agree with you.

We've been told that the ports chosen (3128 for 80 & 3129 for 443) aren't for "brutal security" as i said 😉 but theese appear to be the squid's defaults ports for the service that inspects the packet at the highest level (that's what i have understood).

So, as we can't modify the destination port without modifying the ip destination, we've decided to use the "NAT Destination" method instead of FBF, and it seems to be working 🙂

set security nat destination pool Proxy-192-168-22-1 address 192.168.22.1/32
set security nat destination pool Proxy-192-168-22-1 address port 3128
set security nat destination pool Proxy_s-192-168-22-1 address 192.168.22.1/32
set security nat destination pool Proxy_s-192-168-22-1 address port 3129

set security nat destination rule-set from_Trust_pscc from interface reth2.13
set security nat destination rule-set from_Trust_pscc rule proxy_rule match destination-address 0.0.0.0/0
set security nat destination rule-set from_Trust_pscc rule proxy_rule match destination-port 80
set security nat destination rule-set from_Trust_pscc rule proxy_rule then destination-nat pool Proxy-192-168-22-1
set security nat destination rule-set from_Trust_pscc rule proxy_s_rule match destination-address 0.0.0.0/0
set security nat destination rule-set from_Trust_pscc rule proxy_s_rule match destination-port 443
set security nat destination rule-set from_Trust_pscc rule proxy_s_rule then destination-nat pool Proxy_s-192-168-22-1

Knowing that we're not allowed to use the Proxy to do the port conversion

(

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

), but we must use the FW to do this, is there anything that helps us achieving our goal using FBF?

Thank you in advance for your response.

Hi,

1.1 - Yes

1.2 - The return traffic comes back which ever way you setup the routing. As long as it comes back to the same zone that it left then it will be fine

1.3 - Yes

2 - No not using FBF, you need to use DNAT to do IP+Port converstion

Tim

Hi Tim,

We've applied the destination nat method, and it's working.

Thank you for your support.

Best regards,

Yassine