Forum Discussion
How do i send an ICMP Dest port unreachable on an irule?
- Sep 24, 2016
It appears (on 12.1.1, at least) that the behavior of the
command differs based on whether address translation is enabled. When it is, as I say, an ICMP Port Unreachable message is returned (for UDP traffic). When it is disabled, the behavior you see occurs.reject
There is no way to send a specific, explicit ICMP response from an iRule. However, a "Reject" type server will send an ICMP Port Unreachable in any case. So, you could create a "Reject" virtual server that is bound to no VLAN:
ltm virtual vs-reject { destination 0.0.0.0:any mask any profiles { fastL4 { } } reject source 0.0.0.0/0 translate-address enabled translate-port enabled vlans-enabled vs-index 6 }
Then, in your iRule, instead of using
, forward rejects to this VS:reject
when CLIENT_ACCEPTED { if { ![class match [IP::client_addr] equals server_pools] }{ virtual vs-reject } }
(Notice that the explicit
branch is unnecessary because the VS type is already Forwarding). For me, this produces an identical result for classicforward
(using UDP segments bound for random high-numbered ports), which you appear to be testing here.traceroute
It appears (on 12.1.1, at least) that the behavior of the
reject
command differs based on whether address translation is enabled. When it is, as I say, an ICMP Port Unreachable message is returned (for UDP traffic). When it is disabled, the behavior you see occurs.
There is no way to send a specific, explicit ICMP response from an iRule. However, a "Reject" type server will send an ICMP Port Unreachable in any case. So, you could create a "Reject" virtual server that is bound to no VLAN:
ltm virtual vs-reject {
destination 0.0.0.0:any
mask any
profiles {
fastL4 { }
}
reject
source 0.0.0.0/0
translate-address enabled
translate-port enabled
vlans-enabled
vs-index 6
}
Then, in your iRule, instead of using
reject
, forward rejects to this VS:
when CLIENT_ACCEPTED {
if { ![class match [IP::client_addr] equals server_pools] }{
virtual vs-reject
}
}
(Notice that the explicit
forward
branch is unnecessary because the VS type is already Forwarding). For me, this produces an identical result for classic traceroute
(using UDP segments bound for random high-numbered ports), which you appear to be testing here.I'm running BIG-IP v11.4.0 (Build 2384.0) on this particular F5. We have about 18 F5 Bigip LTM's in service and the goal is to eventually upgrade them to 12.1.1.
On this build it wont let me enable the port/address translation on the vip. In the GUI there is no option for this so I tried in the CLI and they never get enabled.
[rwendt@bigip01a:Active:Standalone] ~ tmsh list ltm virtual anycast-protect
ltm virtual anycast-protect {
destination 10.0.1.0:any
ip-forward
mask 255.255.255.0
profiles {
fastL4 { }
}
rules {
anycast_protect
}
source 0.0.0.0/0
translate-address disabled
translate-port disabled
vs-index 96
}
[rwendt@bigip01a:Active:Standalone] ~ tmsh modify ltm virtual anycast-protect translate-address enabled translate-port enabled
[rwendt@bigip01a:Active:Standalone] ~ tmsh list ltm virtual anycast-protect
ltm virtual anycast-protect {
destination 10.0.1.0:any
ip-forward
mask 255.255.255.0
profiles {
fastL4 { }
}
rules {
anycast_protect
}
source 0.0.0.0/0
translate-address disabled
translate-port disabled
vs-index 96
}
I tried making that reject server that isn't bound on any vlans. Then i used this ip forwarding vs to send it to the reject vs and it sends the ICMP port unreachable. However there is some weird behavior. Its sends alot of those messages now. Maybe because I cannot enable the port/address translation on it? I could send you a tcpdump of this however it was about 3000 packets for a single traceroute.
In any event thanks for the input on all of this. I think upgrading might be in order here.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com