Multiple IP forwarding

[cwjones]

Multiple incoming static IPs @ WAN1, forwarding to specific servers. VIPs / VGroup / Port Forwarding set up (No NAT), and forwarding works internally using secondary IP (can connect to web server), but can't access from outside... times out. My experience with this is limited, so I am not prone to experiment too much.. ;)

Read somewhere that specifying a secondary IP on the WAN1 interface should not be necessary, is that true? That's the only idea I have left, so if that's not it, maybe someone can point me in the right direction..

Thanks!

CW Jones

[yckoh · Accepted solution]

cwjones wrote:

Multiple incoming static IPs @ WAN1, forwarding to specific servers. VIPs / VGroup / Port Forwarding set up (No NAT), and forwarding works internally using secondary IP (can connect to web server), but can't access from outside... times out. My experience with this is limited, so I am not prone to experiment too much.. ;)

Read somewhere that specifying a secondary IP on the WAN1 interface should not be necessary, is that true? That's the only idea I have left, so if that's not it, maybe someone can point me in the right direction..

Thanks!

CW Jones

You do not need to specify secondary IP for VIP configuration.  However you need to make sure that you have setup the policy from outside to inside.  For the destination address, select the VIP that you have created.

YC

[ede_pfau]

The way to use multiple public IPs is to create a VIP for each and to create 'wan' -> 'internal' policies, one for each VIP. You could use a VIP group if all forwarded services ('service' field in the policy) are the same.

If I understand your post correctly you've done just this. How did you test it? Remember you cannot use ping to test a port-forwarding VIP, only the service on that port is serviced.

The FGT will proxy-arp for each VIP, and use the translation defined by it to source-NAT traffic in the other direction, from (internal) server to outside.

If you still have problems post the VIP config for one VIP and it's policy.

[cwjones]

As far as I can tell, yes, I have done the steps correctly.

Testing - I can reach the server from inside the lan using the public IP.. it is forwarded to that server. However from outside, I cannot (from my phone sans wifi, or from home).

I did create a Firewall Address policy -  

Incoming - wan1

Source - all

Outgoing - internal

Destination - VIP Group 

Schedule - always

Service - Service group (+HTTP / HTTPS/ SSH just in case)

Accept

Group elements are typically

VIP - WebAccess80

External - wan1

Type Static NAT

IP Range - public_IP

Mapped IP - 10.10.100.204

Port Forwarding checked

Protocol TCP

External service port 80 / 443 / 22 (separate VIPs)

Map to port 80 / 433 / 22

Created VIP Group from these to use in policy

I can post screen caps if that is preferable

Thanks!

CW

[rwpatterson]

Is your ISP allowing those ports inward? Try using port 65443 on the outside pointed to 443 on the inside. If that works, then it's your ISP. (https://your.domainname.com:65443)

[cwjones]

I noted that as a possible issue as I was reading through posts.. Called Telepacific just to make sure, they assured me that they do not block anything coming in...

Nice to have a method to check it though - thanks!

CW

[oheigl]

You could try to start a sniffer on the CLI and check what's happening.

diagnose sniffer packet any 'host <external_testing_ip>' 4

If you see the packet, your ISP is not blocking anything. Also you should see the forwarded packet with the destination ip translated to the internal ip defined in the VIP. If not, start a flow debug as described in this KB at step 4:

http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD30038&sliceId=2...

Maybe you can then post the output here on the forum, and disguise the external address

[cwjones]

Got sidetracked.. but thanks for the response. Output of these didn't tell me much (I'm no expert) do they need to run longer? 

This is what I got with a short run on the sniffer - public ip 65.60.xx.xx

FG100DXXXXXXXXXX diagnose sniffer packet any '65.60.xx.xx' 4

30.237706 internal in 10.10.0.156.60476 -> 65.60.xxx.xx.443: psh 3935544879 ack 3549504294 30.238312 internal out 65.60.xxx.xx.443 -> 10.10.0.156.60476: ack 3935545140 30.238316 eth1 out 65.60.xxx.xx.443 -> 10.10.0.156.60476: ack 3935545140 30.294918 internal out 65.60.xxx.xx.443 -> 10.10.0.156.60476: psh 3549504294 ack 3935545140 30.294927 eth1 out 65.60.xxx.xx.443 -> 10.10.0.156.60476: psh 3549504294 ack 3935545140 30.297186 internal in 10.10.0.156.60476 -> 65.60.xxx.xx.443: 3935545140 ack 3549504384 30.297211 internal in 10.10.0.156.60476 -> 65.60.xxx.xx.443: psh 3935546600 ack 3549504384 30.391104 internal in 10.10.0.61.53627 -> 65.60.xxx.xx.443: psh 113730147 ack 2728317477 30.391133 internal out 65.60.xxx.xx.443 -> 10.10.0.156.60476: ack 3935546670 30.391136 eth1 out 65.60.xxx.xx.443 -> 10.10.0.156.60476: ack 3935546670 30.391146 internal out 65.60.xxx.xx.443 -> 10.10.0.156.60476: psh 3549504384 ack 3935546670 30.391150 eth1 out 65.60.xxx.xx.443 -> 10.10.0.156.60476: psh 3549504384 ack 3935546670 30.391160 internal out 65.60.xxx.xx.443 -> 10.10.0.156.60476: psh 3549504634 ack 3935546670 30.391163 eth1 out 65.60.xxx.xx.443 -> 10.10.0.156.60476: psh 3549504634 ack 3935546670 30.391174 internal out 65.60.xxx.xx.443 -> 10.10.0.156.60476: psh 3549505012 ack 3935546670 30.391176 eth1 out 65.60.xxx.xx.443 -> 10.10.0.156.60476: psh 3549505012 ack 3935546670 30.391726 internal in 10.10.0.156.60476 -> 65.60.xxx.xx.443: ack 3549505086 30.441700 internal in 10.10.0.62.12962 -> 65.60.xxx.xx.443: psh 2360887271 ack 2640936906 30.497741 internal out 65.60.xxx.xx.443 -> 10.10.0.61.53627: psh 2728317477 ack 113730408 30.497746 eth1 out 65.60.xxx.xx.443 -> 10.10.0.61.53627: psh 2728317477 ack 113730408 30.497763 internal out 65.60.xxx.xx.443 -> 10.10.0.62.12962: psh 2640936906 ack 2360887569 30.497767 eth1 out 65.60.xxx.xx.443 -> 10.10.0.62.12962: psh 2640936906 ack 2360887569 30.498054 internal in 10.10.0.62.12962 -> 65.60.xxx.xx.443: 2360887569 ack 2640936996 30.498074 internal in 10.10.0.62.12962 -> 65.60.xxx.xx.443: psh 2360889029 ack 2640936996 30.498216 internal in 10.10.0.61.53627 -> 65.60.xxx.xx.443: 113730408 ack 2728317567 30.498250 internal in 10.10.0.61.53627 -> 65.60.xxx.xx.443: psh 113731868 ack 2728317567 30.498310 internal out 65.60.xxx.xx.443 -> 10.10.0.62.12962: ack 2360889333 30.498313 eth1 out 65.60.xxx.xx.443 -> 10.10.0.62.12962: ack 2360889333 30.665865 internal out 65.60.xxx.xx.443 -> 10.10.0.61.53627: ack 113731970 30.665873 eth1 out 65.60.xxx.xx.443 -> 10.10.0.61.53627: ack 113731970 30.665892 internal out 65.60.xxx.xx.443 -> 10.10.0.61.53627: psh 2728317567 ack 113731970 30.665896 eth1 out 65.60.xxx.xx.443 -> 10.10.0.61.53627: psh 2728317567 ack 113731970 30.665908 internal out 65.60.xxx.xx.443 -> 10.10.0.61.53627: psh 2728317817 ack 113731970 30.665912 eth1 out 65.60.xxx.xx.443 -> 10.10.0.61.53627: psh 2728317817 ack 113731970 30.665925 internal out 65.60.xxx.xx.443 -> 10.10.0.61.53627: psh 2728318195 ack 113731970 30.665928 eth1 out 65.60.xxx.xx.443 -> 10.10.0.61.53627: psh 2728318195 ack 113731970 30.665941 internal out 65.60.xxx.xx.443 -> 10.10.0.62.12962: psh 2640936996 ack 2360889333 30.665943 eth1 out 65.60.xxx.xx.443 -> 10.10.0.62.12962: psh 2640936996 ack 2360889333 30.665954 internal out 65.60.xxx.xx.443 -> 10.10.0.62.12962: psh 2640937246 ack 2360889333 30.665957 eth1 out 65.60.xxx.xx.443 -> 10.10.0.62.12962: psh 2640937246 ack 2360889333 30.665968 internal out 65.60.xxx.xx.443 -> 10.10.0.62.12962: psh 2640937624 ack 2360889333 30.665971 eth1 out 65.60.xxx.xx.443 -> 10.10.0.62.12962: psh 2640937624 ack 2360889333 30.666087 internal in 10.10.0.61.53627 -> 65.60.xxx.xx.443: ack 2728318269 30.666120 internal in 10.10.0.62.12962 -> 65.60.xxx.xx.443: ack 2640937698

This is partial output from the flow trace -  id=13 trace_id=96 msg="SNAT 10.10.0.204->65.60.xxx.xx:443" id=13 trace_id=97 msg="vd-root received a packet(proto=6, 10.10.0.204:443->10.10.0.1:49381) from internal." id=13 trace_id=97 msg="Find an existing session, id-22b498d9, reply direction" id=13 trace_id=97 msg="enter fast path" id=13 trace_id=97 msg="DNAT 10.10.0.1:49381->10.10.0.179:49381" id=13 trace_id=97 msg="SNAT 10.10.0.204->65.60.xxx.xx:443" id=13 trace_id=98 msg="vd-root received a packet(proto=6, 10.10.0.204:443->10.10.0.1:28603) from internal." id=13 trace_id=98 msg="Find an existing session, id-219f5f38, reply direction" id=13 trace_id=98 msg="enter fast path" id=13 trace_id=98 msg="DNAT 10.10.0.1:28603->10.10.0.179:49228" id=13 trace_id=98 msg="SNAT 10.10.0.204->65.60.xxx.xx:443" id=13 trace_id=99 msg="vd-root received a packet(proto=6, 10.10.0.204:443->10.10.0.1:49381) from internal." id=13 trace_id=99 msg="Find an existing session, id-22b498d9, reply direction" id=13 trace_id=99 msg="enter fast path" id=13 trace_id=99 msg="DNAT 10.10.0.1:49381->10.10.0.179:49381" id=13 trace_id=99 msg="SNAT 10.10.0.204->65.60.xxx.xx:443" id=13 trace_id=100 msg="vd-root received a packet(proto=6, 10.10.0.204:443->10.10.0.1:49658) from internal." id=13 trace_id=100 msg="Find an existing session, id-22b8a018, reply direction" id=13 trace_id=100 msg="enter fast path" id=13 trace_id=100 msg="DNAT 10.10.0.1:49658->10.10.0.7:49658" id=13 trace_id=100 msg="SNAT 10.10.0.204->65.60.xxx.xx:443

?? ideas

Thanks, Wes

[cwjones]

.. forgot to mention - 10.10.0.204 is the internal target for the redirect 65.60.. -> 10.10.0.204 ports 80,443

[ede_pfau]

All these traces are for traffic from internal server to WAN (right?). Could you please post a 'diag deb flow' for real traffic, WAN to internal server?