Console into the firewall as kageeslin suggested, then do a 'get interface ' and look for something like this:
Interface ethernet0/0(VSI):
description ethernet0/0
link up, phy-link up/full-duplex
vsys Root, zone Untrust, vr trust-vr, vsd 0
*ip 192.168.1.1/24 mac abcd.abcd.abcd
manage ip 192.168.1.2, mac abcd.abcd.abcd
ping enabled, telnet enabled, SSH enabled, SNMP enabled
web enabled, ident-reset disabled, SSL enabled
Make sure you are trying to connect to one of your manageable interfaces and also make sure that it has a route back to you (get route). Can the firewall ping your PC?
[edited for additional testing steps]
Once you have console access:
Check the admin ports that the web server is listening on:
get conf | inc admin
Try setting a filter for your connection and debug.
clear dbuf
set ffilter src-ip <your ip address>
debug flow basic
[try the connection again]
sh db str
I'm not sure it's possible to do it quite the way you describe.
You might be able to define a bridge group l3 interface for each vlan, but I'm not sure if you can bind vlan subinterfaces into a bridge group, or just whole ports (in which case that wouldn't work.)
You could put ports 2 and 5 into a bridge group, but you couldn't break out vlan 10 into a different port that way.
Is there a particular reason to have the server attach directly to the SSG, and not to the switch? I typically put everything on the switch and run a single trunk port (firewall-on-a-stick), or a couple of trunks for different VLANs if trunk bandwidth is an issue.
Best Answer
The correct answer is to create a loopback interface. When nothing is plugged into the LAN bgroup, the interface goes "down", and all routes associated with it are removed from the routing table. That's a behavior you want, actually, as it helps when using route-based redundant VPNs - it's the only way for a device to know "that tunnel is down and I should now route to over here".
Okay, so what you do is:
Now you can manage the unit using that loopback IP address, which will always remain reachable; and you did not have to carve out additional address space to do that.
Ensuring that a tunnel remains "up" is an entirely different concern. In ScreenOS, this can be accomplished with the "monitor rekey" option (and "optimized" for good measure if you want to, with a specific destination IP and source port if the outside isn't pingable, and possibly with an interval of 5 instead of 1 if the lines you go over are residential ISPs). That has nothing to do with being able to manage, however. It can give you good indication and advance warning of VPN failure, if you configure a server that receives logs and sends out notifications to staff on "VPN Down". It also has the risk of making your VPNs "flap" if you misconfigure - that is, if the address that Monitor is pinging cannot, actually, be pinged, or if the interval is too aggressive for the quality / latency of your ISP connection(s). That can be handled by, for example, pinging said loopback address through the tunnel: You won't be relying on the external address being reachable to ping.