analyzing tcp or udp port info in ip forwarding mode

 

I've just run into the same problem, is there no work around?

 

 

- John

 

Well, I was going to recommend utilizing the forwarder with a fancy packet filter, but it looks like the F5 packet filtering package doesn't support tcp/udp port range syntax, so a filter to support a standard iptables 1024:65535 port range would be painful indeed.

Just want to add that I'm looking for a solution to the same issue. Trying to give hosts access back into another vlan on specific UDP and TCP ports. Has anyone found the work around?

Set up one network virtual server (0.0.0.0/0) with protocol TCP, binding only to your internal vlan:

virtual tcp_test-std_vip {
   destination any:any
   ip protocol tcp
   vlans internal enable
   rule tcp_forward-rule
}

And another for UDP:

virtual udp_test-std_vip {
   destination any:any
   ip protocol udp
   vlans internal enable
   rule udp_forward-rule
}

Now setup a network forwarding virtual server (0.0.0.0/0) with protocol 1 (ICMP), binding only to your internal vlan:

virtual icmp_test-fwd_vip {
   destination any:any
   ip forward
   ip protocol icmp
   vlans internal enable
}

And of course, the rules for the TCP/UDP forwarding:

rule tcp_forward-rule {
  when CLIENT_ACCEPTED {
    if { [TCP::client_port] > 1024 } {
      forward
    } else { discard }
  }
}
rule udp_forward-rule {
  when CLIENT_ACCEPTED {
    if { [UDP::client_port] > 1024 } {
      forward
    } else { discard }
   }
}

Standard disclaimer...Untested!

Either I'm missing something or my situation is a bit different. I need a host on VLAN2 to be able to initiate connections to the following IP:port conbinations on VLAN1. I'm not doing any load balancing just want to allow or reject the traffic.

 

 

vlan2 ip -> vlan1 192.168.0.1:53 TCP/UDP

 

vlan2 ip -> vlan1 192.168.0.2:53 TCP/UDP

 

vlan2 ip -> vlan1 192.168.0.10:123 UDP

 

vlan2 ip -> vlan1 192.168.0.11:123 UDP

 

vlan2 ip -> vlan1 192.168.0.12:123 UDP

 

vlan2 ip -> vlan1 192.168.0.20:65 TCP

 

vlan2 ip -> vlan1 192.168.0.21:65 TCP

 

vlan2 ip -> vlan1 192.168.0.22:65 TCP

 

vlan2 ip -> vlan1 192.168.0.30:514 UDP

 

vlan2 ip -> vlan1 192.168.0.31:514 UDP

 

vlan2 ip -> vlan1 192.168.0.32:514 UDP

 

vlan2 ip -> vlan1 192.168.0.33:514 UDP

 

 

bloschr, your issue can be solved by creating a network virtual forwarder for vlan 2 enabled on vlan 1 and a forwarder for vlan 1 enabled of vlan 2. Then create packet filters as you've outlined above. No rules necessary.

Sheesh citizen, I was just going to suggest he use packet filters instead... But you are too fast...

I assume that will require I have routes set up in my core network on VLAN1 for IP's in VLAN2. I was trying to avoid that if possible

maybe I misunderstand your configuration.... I assumed vlan 1 and vlan 2 are both defined on the LTM, is this not the case? If the LTM is not the default gateway for these vlan's, then you'll need to get a little more creative. Since this is appearing not to be heading in the direction of rules, feel free to shoot your requirements and a topology diagram to me at jason.e.rahm@erac.com, and I'll see if I can help.

I found this post again through a search and thought that I would try it out.

 

 

Unfortunately citizen_elah's idea doesn't really work 100%.

 

 

Indeed the LTM will let you build the config, and you get forwarding and port inspection in iRules.

 

 

Unfortunately you also get a situation where any connection through the wildcard virtual server is immediately accepted (eg, telnet outward to any IP on any port), then reset if the remote host doesn't have that port open, or the TCP session will continue if the remote host has the port open.

 

 

So it seems that the LTM will-

 

- Accept the wildcard connection from the client (internal side)

 

- Attempt to build the connection to the remote host (external side)

 

then

 

- Reset the connection if the port isn't open on the remote host

 

OR

 

- Proceed normally if the port is open on the remote host

 

 

In summary, it works but its not very elegant.

 

 

What we need is for F5 to fix the forwarding virtual server so that we can do proper TCP or UDP port inspection.

 

 

- John