Forum Discussion

smp_86112's avatar
smp_86112
Icon for Cirrostratus rankCirrostratus
Mar 15, 2012

Wildcard VS Priority Processing

Hi. I am trying to diagnose why an SSH connection is getting terminated after the default idle timeout in the fastL4 profile (300s). The connection from the client is received on the "external" VLAN. My understanding of SOL6459 is that a 0.0.0.0:22 wildcard virtual server would take precedence over a 0.0.0.0:any virtual server, so my expectation is that the idle timeout value should be taken from the fastL4_long_timeout profile. But that's not what is happening. By looking at the connection table, I have confirmed that the idle timeout value is being set based on the default fastL4 profile (300s).

The problem seems to have been introduced recently when the wildcard_ipv4_external2 virtual server was added to the configuration. But since that is not enabled on the "external" vlan, I didn't feel there would be any conflict.

Can someone explain to me what is happening?


ltm virtual vs_0_0_0_0_any {
    destination any:any
    ip-forward
    mask any
    profiles {
        fastL4 { }
    }
    translate-address disabled
    translate-port disabled
    vlans {
        external
        internal1
    }
    vlans-enabled
}
ltm virtual vs_0_0_0_0_ssh {
    destination any:ssh
    ip-forward
    ip-protocol tcp
    mask 255.255.255.255
    profiles {
        fastL4_long_timeout { }
    }
    translate-address disabled
    translate-port disabled
    vlans {
        external
        internal1
    }
    vlans-enabled
}
ltm virtual wildcard_ipv4_external2 {
    destination any:any
    ip-protocol tcp
    mask 255.255.255.255
    pool default_gw_ipv4
    profiles {
        fastL4 { }
    }
    translate-address disabled
    translate-port disabled
    vlans {
        internal2
    }
    vlans-enabled
}

config
design

5 Replies

Sort By
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Mar 16, 2012
    Hi SMP,

     

     

    Are your SSH connections matching the port 22 VS? If you run tcpdump what listener do you see?

     

     

    tcpdump -ni 0.0 -s0 host 10.1.0.15

     

    06:09:16.132461 IP 192.168.1.212.62491 > 10.1.0.15.http: S 200875914:200875914(0) win 65535 in slot1/tmm0 lis=

     

    06:09:16.132522 IP 10.1.0.15.http > 192.168.1.212.62491: S 2293745962:2293745962(0) ack 200875915 win 4380 out slot1/tmm0 lis=http_10.1.0.15_v

     

     

    Do you have a SNAT that the SSH connections could be matching?

     

     

    Aaron
  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Mar 16, 2012
    it seems working correctly for me.

    172.28.19.170 is client.

    200.200.200.101 is sshd.

    200.200.200.10 is selfip (snat automap). 

    [root@ve1023:Active] config  b version|grep -iA 1 version
BIG-IP Version 10.2.3 112.0
Final Edition

[root@ve1023:Active] config  b virtual list
virtual bar {
   translate service disable
   ip forward
   snat automap
   destination any:22
   mask 0.0.0.0
   ip protocol 6
   profiles fastL4_20s {}
}
virtual wildcard {
   ip forward
   snat automap
   destination any:any
   mask 0.0.0.0
   profiles fastL4_10s {}
}
[root@ve1023:Active] config  b profile fastL4_10s list
profile fastL4 fastL4_10s {
   defaults from fastL4
   idle timeout 10
}
[root@ve1023:Active] config  b profile fastL4_20s list
profile fastL4 fastL4_20s {
   defaults from fastL4
   idle timeout 20
}

[root@ve1023:Active] config  tcpdump -nni 0.0 port 22 and not host 172.28.19.80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 108 bytes
06:49:06.357027 IP 172.28.19.170.58504 > 200.200.200.101.22: S 1891381090:1891381090(0) win 5840 
06:49:06.357175 IP 200.200.200.10.58504 > 200.200.200.101.22: S 1891381090:1891381090(0) win 5840 
06:49:06.357871 IP 200.200.200.101.22 > 200.200.200.10.58504: S 3959009223:3959009223(0) ack 1891381091 win 5792 
06:49:06.357881 IP 200.200.200.101.22 > 172.28.19.170.58504: S 3959009223:3959009223(0) ack 1891381091 win 5792 
06:49:06.360748 IP 172.28.19.170.58504 > 200.200.200.101.22: . ack 1 win 46 
06:49:06.360759 IP 200.200.200.10.58504 > 200.200.200.101.22: . ack 1 win 46 
...
06:49:10.150820 IP 172.28.19.170.58504 > 200.200.200.101.22: . ack 2205 win 79 
06:49:10.150832 IP 200.200.200.10.58504 > 200.200.200.101.22: . ack 2205 win 79 
06:49:32.644079 IP 200.200.200.10.58504 > 200.200.200.101.22: R 1925:1925(0) ack 2205 win 0
06:49:32.644099 IP 200.200.200.101.22 > 172.28.19.170.58504: R 2205:2205(0) ack 1925 win 0
  • smp_86112's avatar
    smp_86112
    Icon for Cirrostratus rankCirrostratus
    Mar 16, 2012
    What the heck hoolio, why didn't I know about the listener trick? Great tip, thanks for that. Anyway tcpdump says it is getting processed by the vs_0_0_0_0_any virtual server, which seems right based on what is happening. So I guess the question is why isn't the connection processed by the vs_0_0_0_0_ssh instead, since that seems like it is more specific than any:any. SOL8009 says the value of db TM.ContinueMatching can have an effect (my value is set to true), but only when the VS is down or disabled which is not the case here. SOL6459 says *: takes priority over *:*, so I must be missing something.
  • smp_86112's avatar
    smp_86112
    Icon for Cirrostratus rankCirrostratus
    Mar 16, 2012
    I think I figured it out. My port 22 wildcard has a subnet mask of 255.255.255.255, and SOL6459 says the longest subnet match has the highest priority. I changed the port 22 subnet mask to 0.0.0.0, and now SSH is processed by the port 22 virtual server. Don't know why this cropped up suddenly, but oh well.
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Mar 16, 2012
    Bah... I looked right at the host masks. That's caught me out a few times. Basically, with the /32 mask on the virtual servers, LTM would be looking for a connection made to 0.0.0.0 instead of any host. Glad you figured this out.

     

     

    Aaron