04-12-2012 12:46 PM
Hi Guys,
I need your support regarding the below issue. I'm using ISG 1000 for internet firewall deployment the design is the following
(INTERNAL NETWORK) <---------(Internal routers)---------------> (ISG 1000) <------------------------> (Internet routers)<------>(ISP cloud)
On the interface faing the internal network I used ospf between the firewall interfaces and the internal network .
On the other side static route configured towards the internet routers
for the mile between the ISG and the internet routers a private IPs are assigned . I have been provided with a public internet ranges as this firewall shall be used as a internet firewall doing natting operation + IPSEC
I have trust VR for the internal network and an Untrust VR for the internet facing networks .
I have created a loopback associate it with Untrust zone and terminate the public IP range on and I have tried to traceroute from the ISG console using this interface no hope
I have tried also to make a nat policy from trust to untrust and make DIP from the loopback assigned range and tried to ping from the firewall with no hope also
My questions are :-
1- Is the using of the loopback is it a sufficient way or not ?
2- Making a successful traceroute or ping to the internet from the firewall it self
3- make sure that the tarffic comming from the internal network will be natted to the public range
4- Terminating the IPSEC on the IP used for the loopback
Sorry for very long thread and waiting for your comments .
Thanks
04-12-2012 06:46 PM
04-12-2012 06:50 PM
04-13-2012 01:27 AM
Hi,
You should add Untrust interface to the loopback's interface group:
set interface ethx/y loopback-group loopback.z
This answers all your questions.
1- Is the using of the loopback is it a sufficient way or not ? - Yes
2- Making a successful traceroute or ping to the internet from the firewall it self - Yes. Use trace x.x.x.x from loop.z or ping x.x.x.x from loop.z
3- make sure that the tarffic comming from the internal network will be natted to the public range - Yes. Enable src-NAT to the egress interface IP in Trust-to-Untrust policies. The loopback interface is the egress one.
4- Terminating the IPSEC on the IP used for the loopback - Yes. Configure an Untrust-to-Untrust policy for Any-to-Any that allows IKE. This is required if IPSec is terminated on a loopback interface and intrazone traffic blocking is enabled (default for Untrust zone). Sure, the policy may be more restrictive in relation to the allowed IPs.
04-13-2012 02:44 AM
Thansk nikolay for your help.
04-13-2012 02:56 AM
Many thanks Edouard for you extensive solution and answering back all my questions.
I need clearification for some points below:-
-- Putting the ethx interface in a group with the loopback will not affect the routing on these interfaces I mean if there is routing entries associated already with ethx it will not be affected
3- make sure that the tarffic comming from the internal network will be natted to the public range - Yes. Enable src-NAT to the egress interface IP in Trust-to-Untrust policies. The loopback interface is the egress one.
--In the nat configuration I should configure the untrust interface which is in the same group on the loopback is that right
4- Terminating the IPSEC on the IP used for the loopback - Yes. Configure an Untrust-to-Untrust policy for Any-to-Any that allows IKE. This is required if IPSec is terminated on a loopback interface and intrazone traffic blocking is enabled (default for Untrust zone). Sure, the policy may be more restrictive in relation to the allowed IPs
--Opening any to any IKE policy my be cause a security risk , is there is any other way to use in order to limit this access ? I mean to be able to make termination of the IPSEC on the loopback and have a good restriction at the same time
The last question is how , how should I apply the loopback interface IP configuration ? should I use the whole public IP subent (/29) or should I use only /32 one .
Thanks again your help is really appreciated .
04-13-2012 04:28 AM
Hi,
Here are some more details:
-- Putting the ethx interface in a group with the loopback will not affect the routing on these interfaces - All interfaces added to a loopback group retain their associated routes. Also, a loopback interface cannot be used as a routing interface in the routes.
-- In the nat configuration I should configure the untrust interface which is in the same group on the loopback is that right- There is not such an option in the policy src-NAT. If you activate the src-NAT you can select either a DIP or egress interface IP. The loopback interface is the egres one in this case. If you add another eth interface to the same loopback group, which has a route to Internet, the packets will be also src-natted to the loopback interface IP.
Sure, you can also use DIPs configured on the loopback interface.
--Opening any to any IKE policy my be cause a security risk - Is not, indeed. Theoretically, if the ISP routers are manipulated your FW may be misused for IKE flooding of the foreign hosts. But, as I wrote, the policy may be more restrictive in relation to the allowed IPs. Create an Untrust address object with the IP of the loopback interface and configure two Untrust-to-Untrust policies:
Loopback IP Object - Any, service IKE
Any - Loopback IP Object, service IKE
Any can also be replaced with the known IPs if you have a site-to-site IPSec to the GWs with the static IPs.
Generally you need similar policies for any traffic terminated on (originated from ) the loopback interface (e.g. ping, telnet etc).
The last question is how , how should I apply the loopback interface IP configuration ? - This plays no significant role. The /29-network is already routed by the ISP towards the private eth interface IP. You can configure the loopback interface as /32 and use the rest of addresses for DIPs, MIPs and VIPs. In this case they are in a "foreign" network and you can run accross the certain limitations. You'd better use /29 and configure the NAT objects in their "home" network.
04-13-2012 07:19 AM
Thanks again , what I have done is to associate the interface on the untrust zone with the loopback.1 interface and put it in a one group called loopback.1
when I have trief to ping through the loopback.1 interface i didn't get any response
the get session details below where x.x.x.x is the loop back real ip address
id 524266/s**,vsys 0,flag 00000040/0000/0003,policy 2,time 4, dip 0 module 0
if 252(nspflag 2002811):x.x.x.x/45600->4.2.2.2/1024,1,6261636b2e3
if 9(nspflag 800e04):x.x.x.x/45600<-4.2.2.2/1024,1,00000c07ac01
id 524269/s**,vsys 0,flag 00000040/4080/0023,policy 320002,time 6, dip 0 module 0
if 7(nspflag 800605):192.168.171.26/1->224.0.0.5/1,89,6400f1751
if 3(nspflag 2002010):192.168.171.26/1<-224.0.0.5/1,89,00000000
id 524272/s**,vsys 0,flag 00000040/0000/0003,policy 2,time 4, dip 0 module 0
if 252(nspflag 2002811):x.x.x.x/45500->4.2.2.2/1024,1,6261636b2e3
if 9(nspflag 800e04):x.x.x.x/45500<-4.2.2.2/1024,1,00000c07ac01
id 524273/s**,vsys 0,flag 00000040/0000/0003,policy 2,time 4, dip 0 module 0
if 252(nspflag 2002811):x.x.x.x/45900->4.2.2.2/1024,1,6261636b2e3
if 9(nspflag 800e04):x.x.x.x/45900<-4.2.2.2/1024,1,00000c07ac01
id 524275/s**,vsys 0,flag 00000040/0000/0003,policy 2,time 4, dip 0 module 0
if 252(nspflag 2002811):x.x.x.x/45800->4.2.2.2/1024,1,6261636b2e3
if 9(nspflag 800e04):x.x.x.x/45800<-4.2.2.2/1024,1,00000c07ac01
id 524277/s**,vsys 0,flag 00000040/0000/0003,policy 2,time 4, dip 0 module 0
if 252(nspflag 2002811):x.x.x.x/45700->4.2.2.2/1024,1,6261636b2e3
if 9(nspflag 800e04):x.x.x.x/45700<-4.2.2.2/1024,1,00000c07ac01
id 524286/s**,vsys 0,flag 00000040/4080/0023,policy 320002,time 6, dip 0 module 0
if 7(nspflag 800605):192.168.171.25/1->224.0.0.5/1,89,6400f1751
if 3(nspflag 2002010):192.168.171.25/1<-224.0.0.5/1,89,00000000
I couldn't trace from the loopback as the firewall give an error when I tried to trace from the loopback
the traceroute from the firewall it self terminates at the ISP routers as I come to it with the private ips
BTW i have opened a policy frmo Untrust to untrust and allow ping on it from any to any
any ideas
Thanks
04-13-2012 08:13 AM
Hi,
You should check with your ISP if the public network is routed towards the private IP of the FW.
I would also recommend to enable logging, also on the session start. If you see "Aged out" as a closing reason the FW correctly forwards the packets but does not get any response.
04-13-2012 08:28 AM - edited 04-13-2012 08:28 AM
Thanks for you dedication answering all concerns, below is the traffic log and as shown the reason is the AGE time out
which assist what you were saying I will send to ISP and I will let you know .
FW1(M)-> get log traffic
PID 2, from Untrust to Untrust, src Any, dst Any, service PING, action Permit
==================================================
Date Time Duration Source IP Port Destination IP Port Service SessionID In Interface
Reason Protocol Xlated Src IP Port Xlated Dst IP Port ID PID Out Interface
==================================================
2012-03-15 16:22:46 0:01:01 x.x.x.x 50400 4.2.2.2 1024 ICMP 524256 loopback.1
Close - AGE OUT 1 x.x.x.x 50400 4.2.2.2 1024 2 ethernet1/3.1
2012-03-15 16:22:45 0:01:01 x.x.x.x 50300 4.2.2.2 1024 ICMP 524255 loopback.1
Close - AGE OUT 1 x.x.x.x 50300 4.2.2.2 1024 2 ethernet1/3.1
2012-03-15 16:22:44 0:01:01 x.x.x.x 50200 4.2.2.2 1024 ICMP 524253 loopback.1
Close - AGE OUT 1 x.x.x.x 50200 4.2.2.2 1024 2 ethernet1/3.1
2012-03-15 16:22:43 0:01:01 x.x.x.x 50100 4.2.2.2 1024 ICMP 524254 loopback.1
Close - AGE OUT 1 x.x.x.x 50100 4.2.2.2 1024 2 ethernet1/3.1
2012-03-15 16:22:42 0:01:01 x.x.x.x 50000 4.2.2.2 1024 ICMP 524258 loopback.1
Close - AGE OUT 1 x.x.x.x 50000 4.2.2.2 1024 2 ethernet1/3.1