source ip
3 TopicsLTM :: iRule to Limit Source Addresses
So... here's a weird one. And I understand it's not optimal... ...but say there is a crisis and management sends down the proclamation: "Only allow X sources at a time access to the server pool until the admins can fix XYZ on the systems involved". So we rush to figure out a way to do so... and come up with the below. Other than blasting the table full of addresses (such as a resource exhaustion DDoS against the F5), are there any other caveats that I might not be thinking about here? when CLIENT_ACCEPTED { set hsl [HSL::open -proto UDP -pool syslog-servers.pool] } when HTTP_REQUEST { set source_ip [IP::client_addr] set ip_limit 2000 Delete all IPs table delete -subtable conns -all if { [table lookup -notouch -subtable conns $source_ip] != 1 } { Source IP doesn't exist in table, add to table table add -subtable conns $source_ip 1 900 } else { Source IP is in the table, actively involved, renew the timer table lookup -subtable conns $source_ip } if { [table keys -subtable conns -count] <= $ip_limit } { The current IP count is less than alloted, allow pool access pool $pool_name above variable acquired in prior logic } else { The IP count has been reached. Do not provide pool access. HSL::send $hsl ":: Source IP limit ($ip_limit) hit for pool, redirecting to maintenance page." call maintenance_page.irule::display_page } }193Views0likes1CommentVS and NAT precedence
Hi, I was under impression that when there is NAT and VS defined (both matching incoming packet) then VS always wins. That is the case for SNAT - except when Source Address Translation is set to None on VS and matching SNAT object exists. But still for SNAT there is full control if SNAT should be used or not (even if SNAT is None on VS, we can set Allow SNAT No on Pool). Problem is that there seems to be no such control for NAT. Scenario: Network VS Forwarding (IP) type Source Address: 10.1.20.252/32 Destination Address/Mask: 192.168.104.0/24 Service Port: All Source Address Translation: None Enabled On: VLAN int NAT object Origin Address: 10.1.20.252 NAT Address: 10.128.11.51 Host sending traffic to 192.168.104.0/24 subnet Host IP: 10.1.20.252 - matching both NAT Origin Address and VS Source Address Def GW: BIG-IP Self IP on VLAN int Result: All traffic leaving BIG-IP on VLAN ext has src IP NATed to 10.128.11.51 (NAT Address). What's more, looking and NAT and VS stats it's obvious that traffic is processed by both VS and NAT (same packet count reported on both). Wonder if it is expected behavior? If so it seems that there is no way to prevent NATing src IP for such configuration - only way is to set NAT object to disabled - seems to be a little drastic solution. Piotr308Views0likes1CommentVS and NAT precedence
Hi, I was under impression that when there is NAT and VS defined (both matching incoming packet) then VS always wins. That is the case for SNAT - except when Source Address Translation is set to None on VS and matching SNAT object exists. But still for SNAT there is full control if SNAT should be used or not (even if SNAT is None on VS, we can set Allow SNAT No on Pool). Problem is that there seems to be no such control for NAT. Scenario: Network VS Forwarding (IP) type Source Address: 10.1.20.252/32 Destination Address/Mask: 192.168.104.0/24 Service Port: All Source Address Translation: None Enabled On: VLAN int NAT object Origin Address: 10.1.20.252 NAT Address: 10.128.11.51 Host sending traffic to 192.168.104.0/24 subnet Host IP: 10.1.20.252 - matching both NAT Origin Address and VS Source Address Def GW: BIG-IP Self IP on VLAN int Result: All traffic leaving BIG-IP on VLAN ext has src IP NATed to 10.128.11.51 (NAT Address). What's more, looking and NAT and VS stats it's obvious that traffic is processed by both VS and NAT (same packet count reported on both). Wonder if it is expected behavior? If so it seems that there is no way to prevent NATing src IP for such configuration - only way is to set NAT object to disabled - seems to be a little drastic solution. Piotr170Views0likes0Comments