Forum Discussion

hoolio's avatar
hoolio
Icon for Cirrostratus rankCirrostratus
Jun 14, 2007

TCP port logging/decision-making with a FastL4 profile

Hello,

Can someone provide more info on why MCP validation of iRules prevents using TCP:: commands with a forwarding IP virtual server/fastL4 profile?

The reason I ask, is that I'd like to give a customer a rule which allows them to selectively drop traffic through a 0.0.0.0:0 IP forwarding virtual server based on the source IP/network and/or the destination IP/network and ports. The current restriction on TCP::commands means we can only make IP level decisions. This reduces the value of the rule significantly.

There have been a few posts on this but I haven't seen a definitive answer:

http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&forumid=5&postid=7986

01070394:3: TCP::client_port in rule (tcp_test) requires an associated TCP profile on the virtual server (ipforward_test).

http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&forumid=5&postid=8701

port filtering for a forwarding IP virtual server that uses a fastL4 profile with Loose Initiation and Loose Close enabled

If you either disable MCP validation of rules in the db, or use a trick to bypass the validation, it seems like you can access the port information. This test on 9.2.5 logged the correct ports and the connection worked through the BIG-IP:


when CLIENT_ACCEPTED {
    log the client IP address:port -> destination IP address:port
   set src_port_cmd TCP::client_port
   set dest_port_cmd TCP::local_port
   set src_port [eval $src_port_cmd]
   set dest_port [eval $dest_port_cmd]
   log local0. "client: [IP::client_addr]:$src_port -> [IP::local_addr]:$dest_port"
}

: client: 192.168.101.10:34040 -> 192.168.101.149:80

So if the information is actually available, why does MCP prevent adding a TCP:: command? Is there any downside to accessing the info with a fastL4 virtual server?

Thanks,

Aaron

application delivery
dev
devops
iRules
  • spark_86682's avatar
    spark_86682
    Historic F5 Account
    Jun 14, 2007
    For a forwarding profile, your two choices are "Layer 2" or "IP", either of which can have non-TCP traffic on them, so the TCP::* commands might not be valid on any given packet.

     

     

    For a fastL4 profile, the TCP::* commands are accepted on v9.4.0 (as it seems like they should be), so that's probably a bug that was fixed.

     

     

    All that said, it seems like you have a good workaround.
  • Mark_Porter_979's avatar
    Mark_Porter_979
    Icon for Nimbostratus rankNimbostratus
    Dec 14, 2007
    I'm in the same predicament, but upgrading to 9.4 isn't likely to happen for several months. Luckily I only had 100 ports to lock down, so I used two really ugly packet filter rules.

     

     

    I would still like to be able to do it with an iRule attached to a forwarding vs, though. Aaron mentioned disabling MCP checking in the db - can anyone point me in the right direction on how to do that?
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Dec 14, 2007
    Hi,

    You can use the example workaround from above to get the TCP source and/or destination port, without disabling the MCP validation. The destination port is the port the client made the request to.

    
when CLIENT_ACCEPTED {
    log the client IP address:port -> destination IP address:port
   set src_port_cmd TCP::client_port
   set src_port [eval $src_port_cmd]
   set dest_port_cmd TCP::local_port
   set dest_port [eval $dest_port_cmd]
   log local0. "client: [IP::client_addr]:$src_port -> [IP::local_addr]:$dest_port"
   if {$dest_port > 1024}{
       requested port was over 1024, so drop it
      drop
   } elseif {$dest_port > 100 and $dest_port <= 1024}{
       port was over 100 and less than 1024 so forward the request
      forward
   } else {
       requested port was less than 100, send a RST
      reject
   }
}

    Aaron