VIP Issue

[BWiebe]

Hey all,

I've setup a couple of VIPs with the same external IP to different internal IPs/networks and different ports on a client's firewall running 6.0.3 (previously 6.0.2).

One of the VIPs only listens on TCP 7108 and forwards to a server on the Internal LAN.

The other VIP listens on 22 and is supposed to forward to a server on the DMZ LAN (ftp over ssh).

The issue is that traffic to the second VIP never seems to get to the firewall.  I sniff the IP and port 22, or I sniff the DMZ IP and port 22 and see nothing.  The first VIP to the internal LAN works perfectly.

If I set the second VIP to use port 2222 (for example) and forward to 22, this works fine and responds.  The issue is that I need the 22 to 22 to work.

The client has limited IPs to work with or I'd consider using a different IP entirely.

This, to me, appears to be a bug with forwarding SSH.  I confirmed I have it disabled on all interfaces for management, and don't see a specific Local-IN Policy using it or other policy using it.

If I enable SSH on the WAN interface, it works - so I don't believe it's the ISP blocking the traffic outside the firewall.

Thoughts?

Just an odd issue....never had issues with VIPs before.

Thanks!

[rwpatterson · Accepted solution]

Does TELNET work from the inside?

[rwpatterson · Accepted solution]

Everything looks good from the 10,000 ft view. Let's get an answer on the local and work from there. Please, get the setups online here for the virtual IP setup and the policy.

From the command line:

FGT# show firewall policy <policy_number>

FGT# show firewall vip "<VIP_name>"

if using a custom policy, add:

FGT# show firewall service custom "<custom_service_name>"

[Bogens]

Hi Petterson - Thanks i still can't understand why its not working when policy has been implemented correctly. I will check tomorrow when i got in office. Btw below policy for your perusal.

config firewall policy

edit 14 set srcintf "wan1" set dstintf "internal" "internal13" set srcaddr "all" set dstaddr "SliceCom" set action accept set schedule "always" set service "ALL" next

[rwpatterson]

Two destination interfaces for one object? That's new to me... I do know that it is a group, but still, I wasn't aware you could do that. Is that a newer feature?

[tanr]

Security Policy with multiple interfaces can be turned on as an optional feature.  Not really recommended unless you really need it.

[Bogens]

Actually its like a router on the stick setup.. so yes you can do it. It's like creating a VLAN in an interface although I use other interface for it, btw that "internal" got multiple vlan on it and internal14 is different network. 

[Bogens]

Tars

is that mean it will affect the port forwarding? i don't think so, logically speaking only TELNET is not working here other port forwarding created is working fine.  Beside is like a router-on-a-stick setup a basic and older configuration on networking basis that consists of a router and switch connected using one Ethernet link configured as an 802.1q trunk link.  

[tanr]

Don't know that it would effect port forwarding. 

Though that security policy rule accepting any service from the wan to your internal IP is a little scary!

Since this is a VIP, does your security policy have "match-vip enable" set?

Do you have a local-in-policy that blocks telnet?  That's somewhat common.

Do you have a security policy earlier in your list that might catch the telnet traffic and deny it?

You should attempt to access the VIP by telnet then look at your traffic logs for that service.

[Bogens]

Hi Guys, Below test for the telnet issue I've encounter. SSH is working but telnet cannot. Is there any configuration I miss even internal are not able to telnet.  

FW # execute telnet 20.20.20.18 4001

Trying 20.20.20.18...

Failed to connect to specified unit.

 

FW # execute telnet 20.20.20.18 23

Trying 20.20.20.18...

Failed to connect to specified unit.

 

FW # execute telnet 20.20.20.18 22

Trying 20.20.20.18...

Connected to 20.20.20.18.

SSH-2.0-OpenSSH_7.2

Protocol mismatch.

Connection closed by foreign host.