Internal users cannot ping secondary WAN-address

[Michel_Schuurman]

Looking over things I guess...

Situation:

WAN1 (primary address): Static IP

WAN1 (secondary address): Static IP

WAN2 (primary address): Dynamic IP

From the internet I am able to ping all three IP-addresses. However, internal users cannot.

They can ping both primary addresses but not the WAN1-secondary address.

Obiously ping is enabled in all three cases. 

Since the WAN1-secondary address hosts an application which needs to be accessible from outside as well as inside and DNS resolves to the public IP address users are now not able to connect to this application. 

Does anyone have an idea what is wrong here?

[emnoc]

The diag debug flow is you friend. Did you set allowaccss for ping

config secondaryip     edit 1         set ip x.x.x.x/30         unset allowaccess     next end

and

 set allowaccess fgfm      fortimanager access http      http access https     https access ping      ping access snmp      snmp access ssh       ssh access telnet    telnet access

Ken

[rwpatterson]

Even though they are on the same interface, you still need policies between the two. Are they in place?

[Michel_Schuurman]

You mean that I need a WAN1 - WAN1 policy?

[Dave_Hall]

MichelSchuurman wrote:

You mean that I need a WAN1 - WAN1 policy?

I think they mean an internal->WAN1 (secondary IP) fw policy.  

[rwpatterson]

Wan1-subnet1 <-> Wan1-subnet2

Yes

Think about it this way: Even though the subnets are on the same physical wire, they are on unique subnets. They need to pass through the FGT (their default gateway) to get anywhere that is not on their subnet. We're talking strict IP traffic here, not old school broadcast traffic like NetBEUI and such. So yes, to talk to any device (even on the same interface) that is not on the same subnet as your source device, you need to go through the FGT. The target subnet happens to be on the same physical interface, so it's Wan1 - Wan1.

Been there, done that.

I'll have to go look into that device, but I believe that some policy routes were involved as well. Not sure. Will check if you need.

[Michel_Schuurman]

Create addresses representing the subnets of both the interface and the secondary addresses.

Created policies allowing all traffic:

WAN1/addrWAN1Pri - WAN1/addrWan1Sec

and 

WAN1/addrWAN1Sec - WAN1/addrWan1Pri

Still, unfortunately:

id=13 trace_id=9610 msg="vd-root received a packet(proto=1, X.X.X.X:3->Y.Y.Y.Y.Y:8) from IntUsers." id=13 trace_id=9610 msg="allocate a new session-042326d9" id=13 trace_id=9610 msg="iprope_in_check() check failed, drop"

Where of course X.X.X.X represents the host sending Ping and Y.Y.Y.Y is the secondary IP address on WAN1.

[rwpatterson]

OK. I'm a bit off here. I was referring to pinging objects on the second subnet, not the interface IP itself. Sorry aout that. What model FGT are we referring to?

[Michel_Schuurman]

Bob, thanks for thinking with me...

Situation is like:

                                    BBBB (wan1 primary)                                     bbbb (wan1 secondary) AAAA (internal network)                                     CCCC (wan2 primary)

Ping from AAAA to BBBB successful

Ping from AAAA to CCCC successful

Ping from AAAA to bbbb unsuccessful

Since BBBB is a dirty subnet (was used by spammers before) we requested another subnet for our Exchange server. Through BBBB the server always was reachable from the internal net using the public subnet or the FQDN.

Since we moved the Exchange server to bbbb we can no longer reach the server through the FQDN. Temporarily solved it by creating an entry in the internal DNS but I would like to have it back the way it was.

[rwpatterson]

Have you tried flipping the two addresses? Make the primary secondary and vice-versa?