Source routing with iRules

Hi Ed,

For performance and ease of management, you could combine all of the addresses/subnets that have a common destination IP into an address datagroup and then use matchclass (9.x) or class match (10.x) to look up the client IP. To check whether a match is being made, you could add logging to the iRule:

when CLIENT_ACCEPTED {
   log local0. "[IP::client_addr]:[TCP::client_port]: destination [IP::local_addr]:[TCP::local_port]"

    Check if client IP is in the my_subnets_class datagroup
   if {[class match [IP::client_addr] equals my_subnets_class]}{
      log local0. "[IP::client_addr]:[TCP::client_port]: Matched my_subnets_class, using 10.130.32.1"
      node 10.130.32.1
   } else {
      node 10.130.4.1
      log local0. "[IP::client_addr]:[TCP::client_port]: Matched my_subnets_class, using 10.130.32.1"
   }
}

If you're testing with ICMP, make sure your virtual server type is defined as all protocols.

Aaron

Hi Aaron

 

 

I have made the changes as suggested as I can see that this has tidied up the configuration so thanks for that.

 

 

I still have a problem in that I cannot hit the back-end networks though;

 

 

I am still getting the ICMP reverse path check on the wrong interface of the PIX;

 

 

 

2010-12-08 17:20:40 Local4.Debug 172.25.0.8 Dec 08 2010 17:20:40: %PIX-7-609001: Built local-host schools-portal:10.130.33.21

 

2010-12-08 17:20:40 Local4.Info 172.25.0.8 Dec 08 2010 17:20:40: %PIX-6-302020: Built outbound ICMP connection for faddr 10.130.33.21/0 gaddr edjones-pc/1 laddr edjones-pc/1

 

2010-12-08 17:20:40 Local4.Alert 172.25.0.8 Dec 08 2010 17:20:40: %PIX-1-106021: Deny ICMP reverse path check from edjones-pc to 10.130.55.12 on interface dmz-servers

 

 

so the traffic is still trying to route back down the default gateway of 10.130.4.1 and not the school-portal gateway of 10.130.32.1

 

 

The traffic must be getting to the F5 in order for it to send it back down the wrong gateway so I suspect that the source routing profile isn't working. Any ideas?

 

 

I also made sure that the virtual server incvluded all protocols as I am testing with ICMP.

 

 

Regards,

 

 

Ed

 

Ed,

 

 

What are the logs from the F5 saying? The iRule above will log to /var/log/ltm, and to the logs > ltm section of the config utility (gui)

Yes, logs and a simple network diagram would definitely help.

 

 

Aaron

Hi both,

 

 

Sorry about the delay in replying. We have had a VoIP phone roll-out over the last week so I have been heavily involved in the setup of that.

 

 

There is nothing in the logs for this iRule so I can't post anything in relation to that.

 

with regard to the network diagram it is as follows;

 

 

incoming traffic (172.16.20.0/24)

 

|

 

[ PIX (Cisco 525) ] - ACL's permit traffic

 

10.130.4.1 | | 10.130.32.1

 

| |

 

| |

 

10.130.4.10 | | 10.130.32.10

 

[ F5 Big IP (NAT addressing) ] - dg on F5 is 10.130.4.1

 

10.130.8.10 | 10.130.52.10

 

| |

 

10.130.8.0/22 10.130.52.0/24

 

| |

 

| |

 

[HP Switch] [HP Switch 5308XL] - dg 10.130.52.10 dg - 10.130.8.10 Routed

 

networks 10.130.52.0/24. 10.130.52.0/24,

 

10.130.54.0/24, 10.130.55.0/24

 

 

I have setup NAT addresses on the F5 to map to the backend networks e.g. 10.130.33.18 > 10.130.52.12 (this works) however 10.130.33.21 > 10.130.55.12 doesn't work. This is where I get the deny ICMP reverse path check. If I put routes on the F5 for the backend networks then I receive ICMP packets back but the routing iRule sees no traffic. Do i really need to setup routes on the F5 as without then I am seeing traffic on the PIX but through the wrong interface. If I get the iRule working so that it source routes the traffic through the correct interface then this is the ideal solution.

 

 

Regards,

 

 

Ed

 

 

Regards,

 

 

Ed

If it helps the current syntax of the iRule is;

 

 

when CLIENT_ACCEPTED {

 

log local0. "[IP::client_addr]:[TCP::client_port]: destination [IP::local_addr]:[TCP::local_port]"

 

 

Check if client IP is in the DMZ_Inside datagroup

 

if {[class match [IP::client_addr] equals DMZ_Inside]}{

 

log local0. "[IP::client_addr]:[TCP::client_port]: Matched DMZ_Inside, using 10.130.32.1"

 

node 10.130.32.1

 

} else {

 

node 10.130.4.1

 

log local0. "[IP::client_addr]:[TCP::client_port]: Matched DMZ_Inside, using 10.130.4.1"

 

}

 

}

 

 

This is applied to the Virtual server which is applied to the DMZ interface (10.130.52.0/22)

Hi all,

 

 

Any news on this please?

 

 

All help would be greatly appreciated. Thanks.

 

 

Ed

Hi Ed,

 

 

The virtual server would need to be enabled on the VLAN that the clients are coming into LTM on. If you don't see the iRule logging at least the first CLIENT_ACCEPTED statement, then they're not getting to the virtual server.

 

 

If you're still stuck, try emailing me at hooleylists at gmail dot com.

 

 

Aaron

Thanks very much for that Aaron... I am on Holiday for a couple of days so will review the config and get back to you when I return...

 

 

In the mean time I'll give the logging a go and hopefully get some output.

 

 

Regards,

 

 

Ed