Access by https and ssh

Hi Marta,

 

 

You can enable specific ports on the self IP's using the port lockdown settings on each self IP:

 

 

 

Specifies the protocols and services from which this self IP can accept traffic. Note that fewer active protocols enhances the security level of the self IP and its associated VLANs.

 

 

* Allow Default: Activates only the default protocols and services. You can determine the supported protocols and services by running the b self allow list command on the command line.

 

* Allow All: Activates all TCP and UDP services on this self IP.

 

* Allow None: Specifies that this self IP accepts no traffic. If you are using this self IP as the local endpoint for WAN optimization, select this option to avoid potential port conflicts.

 

* Allow Custom: Expands the Custom List option, where you can specify the protocols and services to activate on this self IP.

 

 

 

Aaron

You can run tcpdump on LTM to see what's happening:

 

 

tcpdump -nni 0.0 host SELF_IP

 

 

Then try establishing an SSH and/or HTTPS connection with the self IP in the tcpdump command. If the request makes it to LTM, then you can look at any IP/port restrictions that might be configured in packet filters or the daemons themselves.

 

 

Aaron

Hi Aaron!

 

 

this is what appears with the tcpdump: (I do not see anything which can give me a clue about what it's happening.) I hope you can help me

 

 

[root@bigip01:Standby] config tcpdump -nni 0.0 host 172.28.100.250 | grep 172.28.108.17

 

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

 

listening on 0.0, link-type EN10MB (Ethernet), capture size 108 bytes

 

10:14:14.212251 IP 172.28.108.17.49942 > 172.28.100.250.443: S 3264292511:3264292511(0) win 8192

 

10:14:17.206501 IP 172.28.108.17.49942 > 172.28.100.250.443: S 3264292511:3264292511(0) win 8192

 

10:14:23.205966 IP 172.28.108.17.49942 > 172.28.100.250.443: S 3264292511:3264292511(0) win 8192

 

10:14:54.700369 IP 172.28.108.17.49960 > 172.28.100.250.22: S 370168781:370168781(0) win 8192

 

10:14:57.700537 IP 172.28.108.17.49960 > 172.28.100.250.22: S 370168781:370168781(0) win 8192

 

10:15:03.700099 IP 172.28.108.17.49960 > 172.28.100.250.22: S 370168781:370168781(0) win 8192

 

1319 packets captured

 

1319 packets received by filter

 

0 packets dropped by kernel

 

 

Thank you!

 

Hello Marta,

 

 

the pcap shows SYN traffic from 172.28.108.17 to selfip 172.28.100.250 but it looks like the traffic just gets dropped (no SYN, ACK) sent back. Do you have any packet filters configured under Network>Packet Filters that might be dropping the traffic? Packet filter logs would show drops, provided the packet filter rule has logging enabled.

 

 

Do other Self IP's have the same issue?

 

 

Hello Cspillane,

 

 

No, I haven't any Packet Filters configured and it is disabled. (We are very newbie), and yes, it happens the same on other Self Ip.

 

 

Moreover, the weird thing is we have configured another LTMs in the same conditions (this is the development LTM), and they work, but I do not understand why not here :-/

Do you have restrictions in /etc/hosts.allow? Can you check the /var/log/secure file and see if anything is logged when the connection attempt is dropped?

 

 

Aaron

No, I don't think so. Look:

 

 

/etc/hosts.allow

 

sshd : 127. : spawn (/usr/bin/autohost.sh %a)

 

in.tftpd : 127.

 

 

sshd : ALL

 

big3d : ALL

 

snmpd : 127.

 

 

/var/log/secure

 

Apr 15 11:16:55 local/bigipcolt01 notice httpd[2995]: 01070417:0: AUDIT - user admin - RAW: httpd(mod_auth_pam): user=admin(admin) partition=[All] level=Administrator tty=/bin/false host=172.28.108.17 attempts=1 start="Thu Apr 15 11:16:55 2010".

 

Apr 15 11:44:30 local/bigipcolt01 notice httpd[4328]: 01070417:0: AUDIT - user admin - RAW: httpd(mod_auth_pam): user=admin(admin) partition=[All] level=Administrator tty=/bin/false host=172.28.108.17 attempts=1 start="Thu Apr 15 11:16:55 2010" end="Thu Apr 15 11:44:30 2010".

 

 

 

 

 

If the client and self IP's aren't on the same subnet, you'll need to have a default or static TMM route. You can define this under Network >> Routes.

 

 

Aaron

Hi Marta,

 

 

personally I'd run a 'full_box_reboot' or a 'bigstart restart' then check the process come up successfully with 'bigstart status'.

 

 

have the http and ssh daemons to appear in the bigstart status? Because they do not appear... :-/