one external with several external IP Adresses. one internal with 192.168.255.1/24 as IP on DMZ nic with 172.21.0.0/16
We have also a second firewall (ceckpoint) witch connects some other IP subnets together. Personaly I'd like to switch this all toghether to ISA 2004 - but sometimes I have to deal with political decisions which can not be changed easily.
This second firewall has the internal IP of the ISA internal LAN 192.168.255.2/24. There are additional IP networks 172.30.0.0/16 and 18.104.22.168/16 configured.
On my ISA 2004 I added routes: route add 172.30.0.0 mask 255.255.0.0 192.168.255.2 route add 172.20.0.0 mask 255.255.0.0 192.168.255.2
I can now ping from ISA to this network without any problems.
My clients have as default gateway the ISA 2004 192.168.255.1.
If a client form subnet 192.168.255.0/24 connects to 172.30.0.0/16 the IP package is routed to ISA 2004 and ISA 2004 sends the package to 192.168.255.2 and the way is clear. The same routing table with the same IP addresses worked well with ISA 2000.
Now, my problem is that ISA 2004 obviously also filters any traffic crossing / touching the internal NIC 192.168.255.1.
So I created a rule witch allows alls outbound traffic from subnet 192.168.255 to 172.30.0.0 and 172.28.0.0 and an additional rule vice versa. With this rules traffic between the subnets is open.
But even with this rule there is traffic to some IP ports which is denied. And I do not get why:
Original Client IP Client Agent Authenticated Client Service Server Name Referring Server Destination Host Name Transport MIME Type Object Source Source Proxy Destination Proxy Bidirectional Client Host Name Filter Information Network Interface Raw Payload Source Port Processing Time Bytes Sent Bytes Received Result Code HTTP Status Code Cache Information Error Information Log Record Type Log Time Destination IP Destination Port Protocol Action Rule Client IP Client Username Source Network Destination Network HTTP Method URL Raw IP Header 192.168.255.127 SRVBMSHQ20 - TCP - No - 192.168.255.1 00 50 0a ad 5f d6 6b 8a 0b ea 11 91 60 12 16 d0 0d 23 00 00 80 0 0 0 0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED 0x0 0x0 Firewall 11.08.2004 11:09:59 172.30.20.4 2733 Unidentified IP Traffic Denied Connection 192.168.255.127 Internal Internal - - 45 00 00 2c 7f a4 00 00 40 06 7a dd c0 a8 ff 7f ac 1e 14 04
First I tried a rule with the following setting: From: Internal To: Internal Protocols: All Outbound Traffic
The network object "Internal" has all internal IP ranges assigned.
This did not work, so I created subnet objects for the different IP subnets. And than created one rule from subnet 192.168.255.0/24 to 172.30.0.0/24 and another rule vice versa. Both rules have "All Outbound Traffic" as protocol. The rules are the first and the second rule in my policy order.
Obiously this works for the known protocols of ISA 2004. But this does not work for unknown Ports.
For firewall clients, "all protocols" also includes the ports not explicitly defined in ISA server. However, this does not apply to secure NAT clients. For this case, you have to make a "User defined protocol" which include all possible tcp and udp ports with secondary connections on all possible udp and tcp ports in both directions. Another solution is of course to install the firewall client if possible.
A client from the network 192.168.255.0/24 with the default gateway to the ISA 2004 server is able to use ressources of the network 172.30.0.0/16 without any problems. When I ping a device a also get an additional routing entry in the routing table:
When I try to ping from 172.30.0.0/16 to 192.168.255.0/24 the device in the network 192.168.255.0 does not get this additional route. The ping itself is working. But any other application like file sharing or remote desktop doesn't work.
The traffic from 192.168.255.0 to 172.30.0.0 is automatically redirected (I suppose ICMP redirect?!?) to the checkpoint firewall with IP 192.168.255.2. So the traffic does not go to the ISA 2004 with IP 192.168.255.1 and than to the checkpoint. It is going directly.
The traffic form 22.214.171.124 to 192.168.255.0 is always routed to the checkpoint with IP 172.30.1.1 in on LAN and 192.168.255.2 in the other LAN and go's directly to the target computer. The answer traffice of the request which sources form 192.168.255.0 and targets to 172.30.0.0 is then returned to the default gateway which is 192.168.255.1 instead of directly being send back to 192.168.255.2.
So the way for the IP packeges is differnt and ISA 2004 is filtering the traffic with the following result code: 0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED.
So now I know the source of my problems I'm unable to tell if this is a problem of my ISA 2004 or of the CheckPoint.
quote:Originally posted by ketilgri: For firewall clients, "all protocols" also includes the ports not explicitly defined in ISA server. However, this does not apply to secure NAT clients. For this case, you have to make a "User defined protocol" which include all possible tcp and udp ports with secondary connections on all possible udp and tcp ports in both directions. Another solution is of course to install the firewall client if possible.
From: Central Florida
Frank, I have had the same problem with ISA2004. I originally posted this in the forums back in July, see my posts:( Routing???) I have multiple companies that connect through different routers over multiple T-1's with our network (Different Forests with Trusts and using MIIS). With ISA 2K it was no problem as ISA didnt "bother" traffic defined in RRAS that ran over the internal nic. After installing ISA2004, I have had nothing but problems with the error: 0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED. I still havent found a viable solution and have had to pull out my old ISA2K server and use it until someone can find a "legitimate" way to make this work. Ketil's Suggestion of "For firewall clients, "all protocols" also includes the ports not explicitly defined in ISA server. However, this does not apply to secure NAT clients. For this case, you have to make a "User defined protocol" which include all possible tcp and udp ports with secondary connections on all possible udp and tcp ports in both directions. Another solution is of course to install the firewall client if possible." is not a viable answer. I dont have the time or resources to sit and watch every protocol used between our companies and check every optional port they may use and then create rules for this. I have been looking at Tom's recent article about using DMZ's, this might be a solution, by moving the different WAN Routers into different DMZ's, and for you to move your Checkpoint to a DMZ which would force all traffic through the ISA Server. Another option I have been thinking about is to setup another server (possibly an internal DNS Server) as the RRAS Server (Act as the default router not for Remote Access) and Default Gateway, then point internet only traffic to the ISA2K4 Server, I am not sure how this will affect access to OWA, Sharepoint, and other externally available service. These are just thoughts, I have not tested any of these yet (Three Hurricanes in a month tend to increase your workload as deadlines dont change, not to mention trying to get your personal life back to normal, on a lighter note, I have mastered living with out power for weeks on end and using a chainsaw with rationed gas!), I do plan to throw these two scenarios into my test network and see what happens, in the meantime if you or anyone has come up with a "legitimate" way to route multiple networks I would love to see the solution!
From: Central Florida
Tom, I have been reading more and more posts on this internal network behind a network issue with the dropped packets. Is this problem possibly being caused by our "smart" network switches that learn the OSPF by default, bypassing ISA and connecting directly to our internal routers? I feel this is definitely an issue Microsoft needs to take a look at. Sure we can use ISA2K4 as our outer firewall but we cannot use it for internal routing of multiple WAN's like we did in ISA2K without a major headache "Do more with less??" Let me know your thoughts. This really seems to be the major downfall of ISA2K4.
From: Albuquerque NM USA
The 0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED issue you're talking about is legitimate behavior on the part of the ISA Server 2004 firewall. I have noticed this in the following scenario:
In this scenario, the web server, which is a SecureNAT client (its default gateway is pointed at the inside interface of the ISA Server), is replying to web traffic initiated from another trusted network, but since the ISA firewall did not see the initiating part of the conversation, it drops the traffic.
There are several solutions to this problem. One is to update the routing tables on the SecureNAT clients so that replies to the traffic don't pass through the ISA Server. Of course, this becomes unmanageable the more SecureNAT clients there are. Another solution is to add another router or layer 3 switch in between the ISA Server and the rest of the trusted networks.
[ January 05, 2005, 12:26 AM: Message edited by: Bill Stewart ]
From: Central Florida
Thanks Bill, So basically we can no longer use the router functions available in Windows on the ISA2K4 machine. I think this was a great feature with ISA2K but I understand the need with the new firewall to move the routing off of ISA. This has confirmed what I thought all along, I just could not get anyone to confirm it.
This is exactly what I had to do prior to ISA2K using SonicWall Firewalls. Not a big deal just thought there might be some "magic" way to make it work. My scenario of using an internal DNS server for routing, assigning the default gateway to all of my LAN clients to the DNS/Routing Server and then setting up the DNS/Routing servers routing table to reflect all of the appropriate network paths should take care of the problem. This means the only traffic the ISA Server will see is anything destined for the internet and from the internet.
As far as I can tell, this problem only occurs when routing within the same network (e.g. from internal to internal). Does anyone know if there is any reason to pass traffic through the firewall code in this case? Wouldn't these problems be solved easily if ISA2004 code would be adjusted to just pass any traffic that enters and leaves the machine on the same network card without filtering? Security-wise this filtering does not add much since a client could easily circumvent it by changing it's own routing table and sending the packets directly to the destination.
I am having this very same problem. I have to configure static routes on my servers that need to communicate to other subnets even though I have the route defined on the ISA 2004 box. Why didn't anyone mention that the routing capability was removed from this product on internal traffic. Like someone already said, Going back to manual configuration is certainly not "doing more with less".
Totally agree. It's an issue that ISA2004 doesn't route internal subnet traffic. I've been working on this same problem not realizing ISA2004 couldn't route this kind of traffic.
OK.. I really need help. Based on the subnet routing limitation, I need to reroute internal subnet traffic around ISA. Right now I'm focusing just on traffic between 192.168.1.0 to/from both 192.168.2.0 and the Internet.
I created a new network diagram which is below to do this. Below the diagram, I'll explain my routing problem.
I now have problems with my routing & rule logic. Here's where I'm at..
1. I can now tracert from a 192.168.1.x PC to HongKong 192.168.2.1 (Yes!) 2. I can not do any higher features to 192.168.2.1 like RDC, Shares, etc. 3. I can not tracert from ISA to 192.168.2.1. destination not reachable error 4. I created a rule in the Watchguard that all outgoing (non-VPN tunnel traffic) of protocols HTTP, HTTPS, FTP, POP3, and SMTP be redirected to 192.168.1.2 (which is ISA's internal NIC). To provide application level filtering/blocking. I'm not sure this is working as none of the protocols are reaching the internet through ISA. 5. Another Watchguard route is all incoming traffic (non-VPN tunnel) of protocols HTTP, HTTPS, FTP, POP3, etc be redirected to 192.168.20.1 (WG port to fwd to ISA external).
The ISA logs are giving me a run for my money and also what is missing or needs to be opened to make this work.
Also, the Watchguard on port 192.168.1.1 (the default gateway) is dumping lots of DENY errors into its log for traffic trying to go directly to the internet. The traffic should had been redirected to 192.168.1.2 not DENIED.
My goal is simple. All VPN-VPN traffic should flow directly through the Watchguard. All non VPN traffic should be redirected to ISA for processing. Does anyone have examples or routing paths/entries to help this work?