Can not access server's on public ip's

[OliverDarvall]

Guys,

We have a core switch with two fibre lines connecting us through two different ISP's to the internet. These ISP's have provided us with a range of public ip's each. We have a few routers on some of these ip's and they are working fine and we can access them externally (telnet and ssh).

I am now busy setting up two servers, one on each ISP with their respective public ip's. I can ping the core switch and the isp gateways from the servers and from the core. I have triple checked that there are no active firewalls and I can see that the http ports are open and accessible (TcpView). But for the life of me I can not access those servers externally. I am now completely stumped. I do suspect though that it is a routing problem through the core.

And herewith the relevant parts from my Core switch's config:

version 12.2
service tcp-keepalives-in
service tcp-keepalives-out
!
hostname SMS-CORE
!
no aaa new-model
clock timezone ZAR 2
no ip source-route
!
mls netflow interface
mls cef error action reset
!
spanning-tree mode pvst
spanning-tree portfast edge default
!
vlan internal allocation policy ascending
!
interface FastEthernet3/25
 switchport
 switchport access vlan 153
 switchport mode access
!
interface FastEthernet3/31
 switchport
 switchport access vlan 153
 switchport mode access
!
interface FastEthernet3/35
 switchport
 switchport access vlan 153
 switchport mode access
!
interface FastEthernet3/37
 switchport
 switchport access vlan 20
 switchport mode access
!
interface FastEthernet3/47
 switchport
 switchport access vlan 20
 switchport mode access
!
interface FastEthernet3/48
 ip address 192.168.2.2 255.255.255.252
!
interface Vlan1
 no ip address
!
interface Vlan20
 ip address PUBLIC_IP1 255.255.255.240
!
interface Vlan153
 ip address PUBLIC_IP2 255.255.255.248
!
ip classless
!
ip route 0.0.0.0 0.0.0.0 192.168.2.1
!
ip local policy route-map PUBLIC
!
access-list 100 permit ip ISP2_NETWORK 0.0.0.7 any
access-list 101 permit ip ISP1_NETWORK 0.0.0.15 any
!
route-map PUBLIC permit 10
 match ip address 100
 set ip default next-hop PUBLIC_GW2
!
route-map PUBLIC permit 20
 match ip address 101
 set ip default next-hop 192.168.2.1
!

Any  ideas guys, I am at my wits end here ....

Thanks as always !

[OliverDarvall]

Some more info. I have tried setting the Default Gateways(s) on Server1 and Server2 to the Core's ip address, to the respective ISP gateway addresses and tried local policies. None of it worked.

[SANTHOSHKUMAR SARAVANAN]

Hi Oliver , 

       Have you got IP Address assigned to your server from the same segment ?? like for server 1 

ip address PUBLIC_IP1 255.255.255.240

and for server 2 

ip address PUBLIC_IP2 255.255.255.248

What is the gateway IP address assigned for both servers .

HTH

Sandy

[OliverDarvall]

Sandy, yes each server has an IP address assigned from the range from a respective ISP and that same ISP's gateway address is used as the Default Gateway.

[SANTHOSHKUMAR SARAVANAN]

Hi Oliver ,

      Gateway IP address for server is your SVI VLAN of your Switch ??

[OliverDarvall]

No, I am using the ISP gateway addresses (I can ping them from the server).

[SANTHOSHKUMAR SARAVANAN]

Hi 

 can you do trace route from your server to some public IP address , similarly do a trace route from your VPN router , which is connected in same VLAN . 

[OliverDarvall]

I have changed both routers to now point their gateways to the SVI VLAN of the core switch. It has actually improved the situation somewhat.

When I now do a test from an external PC and do a "telnet server_ip 80" then connection actually seems to connect instead of just timing out as it usually did. Also in a browser I go http://server_ip and something happens, although the page is empty, but no connection errors as before.

[OliverDarvall]

I eventually managed to resolve the issue with one of the servers (it turns out that server2's network card was bust, transmits but does not receive). I added a local policy to set the default gateways on the core. Then I added a route-map on the interfaces to set the next hops. I then also had to remove the default gateway as setup on the server and replace it with a few static permanent routes. Everything seemed fine after that.