Acessing to Virtual IP from the inside

[jfernandz]

therHi everyone, 

I've created a Virtual IP to forward the TCP port 10000 to 80 TCP in a client with the IP 192.168.1.12, so the details are:

0.0.0.0 -> 192.168.1.12 (TCP: 10000 -> 80)

Also I've created a policy so I can access to that host from the outside when I do a request at <office.public.ip>:10000 and does work as expected. I've basically followed this post in the knowledge base. 

However, I'm experiencing something unexpected, when I try to access to <office.public.ip>:10000 from another interface (VLAN) I cannot reach the host, just when I try to access from outside (another different internet connection) why is this? 

To put you a little more in context ... I'm doing this in my company, so I can reach the host from my home, but not from the office itself. Also ... the ISP gave me a IP to use as a gateway in a static route (which is different than the public IP of the connection in the office) and also I have another different IP/Netmask for the WAN1 interface (also different than the public IP and the IP for the static route). When I try to reach the host by requesting <ip.wan1.interface>:10000 it works as expected, but again, i cannot reach it when I request <office.public.ip>:10000 from the office itself, only works when I do that request from outside. 

I know when I'm inside (in the office) I don't need actually to access that host via <office.public.ip> but I'm curious because apparently I should be able to use <office.public.ip>:10000 in the same way than I'm able to use just the private local IP (192.168.1.12).

What do you think? Thank you all.

   

[jorge_americo]

I believe the problem is the rule. does the vlan in question have a rule that allows this access? Keep in mind that your request will go up to the firewall and down again. then the rule must have nat of the interface so that there is no asymmetric routing. show your rules.

[jfernandz]

jorge.americo wrote:

I believe the problem is the rule. does the vlan in question have a rule that allows this access? Keep in mind that your request will go up to the firewall and down again. then the rule must have nat of the interface so that there is no asymmetric routing. show your rules.

These are the policies that could be interfering

+----+----------------------+------------------+-----------+------------+ | Id   | Source               | Destination   | Service  | NAT       | +----+----------------------+------------------+-----------+------------+ | internal1 -> wan1                                                              | +----+----------------------+------------------+-----------+------------+ | 2    | 172.20.1.0/24    | all                  | all          | enabled  |  +----+----------------------+------------------+-----------+------------+ | wan1 -> internal1                                                              | +----+----------------------+------------------+-----------+------------+ | 26  | all                       | created VIP   | all         | enabled  | +----+----------------------+------------------+-----------+------------+

Destination and source are, as you know, address objects, except the created VPI, which is the one I've shown, 0.0.0.0 -> 192.168.1.12 (TCP: 10000 -> 80).

But I don't see any problem with this.

[jorge_americo]

# diag debug enable [size="2"]# diagnose debug flow filter saddr x.y.w.z[/size] # diag debug console timestamp enable # diag debug flow show iprope enable # diag debug flow trace start 100 # diag debug enable

where x.y.w.z is the internal ip of the machine you are going to use for testing

use the machine x.y.w.z for teste and show the debug please.

I believe that an internal to internal rule is missing and, if the interface is set on the vip, remove.

  see this .  https://kb.fortinet.com/k....do?externalID=FD36202

[jfernandz]

jorge.americo wrote:

# diag debug enable [size="2"]# diagnose debug flow filter saddr x.y.w.z[/size] # diag debug console timestamp enable # diag debug flow show iprope enable # diag debug flow trace start 100 # diag debug enable

where x.y.w.z is the internal ip of the machine you are going to use for testing

use the machine x.y.w.z for teste and show the debug please.

I believe that an internal to internal rule is missing and, if the interface is set on the vip, remove.

  see this .  https://kb.fortinet.com/k....do?externalID=FD36202

Shouldn't I try to access <office.public.ip>:10000 before dumping the trace with `# diag debug flow trace start 100`? 

Also ... what do you mean with `the machine you are going to use for testing`? the machine from I'm trying to access to 192.168.1.12 or the 192.168.1.12 itself? 

Also ... there is already a policy for accessing internally, in fact I can access to the web interface into 192.168.1.12 but I have to use that local IP, I cannot access using the <office.public.ip>:10000 (from inside, I mean, just from outside)

[jorge_americo]

jfernandz wrote:

jorge.americo wrote:

# diag debug enable [size="2"]# diagnose debug flow filter saddr x.y.w.z[/size] # diag debug console timestamp enable # diag debug flow show iprope enable # diag debug flow trace start 100 # diag debug enable

where x.y.w.z is the internal ip of the machine you are going to use for testing

use the machine x.y.w.z for teste and show the debug please.

I believe that an internal to internal rule is missing and, if the interface is set on the vip, remove.

  see this .  https://kb.fortinet.com/k....do?externalID=FD36202

Shouldn't I try to access <office.public.ip>:10000 before dumping the trace with `# diag debug flow trace start 100`? 

Also ... what do you mean with `the machine you are going to use for testing`? the machine from I'm trying to access to 192.168.1.12 or the 192.168.1.12 itself? 

Also ... there is already a policy for accessing internally, in fact I can access to the web interface into 192.168.1.12 but I have to use that local IP, I cannot access using the <office.public.ip>:10000 (from inside, I mean, just from outside)

As I understand it. you try to access office.public.ip from outside and it works. but the internal using the same VIP ip (office.public.ip) does not work correct?

The idea is to use a machine from the internal network, which is not working, and generate the debug.

Did you even look at the link?

[jfernandz]

jorge.americo wrote:

[...]

Did you even look at the link?

Yes but I'm not sure the situation was the same, in the link the machine which is being mapped is connected to the dmz interface, and in my case it's connected to an internal (physical) interface.

Anyway ... you have here the trace

[jorge_americo]

there is no connection being initiated for port 10000 in log. the debug idea. was to stop other connections. but Ok. As for the link I sent, I was able to see the question of the rule. in this case I believe that you need an internal to internal rule.

[jfernandz]

jorge.americo wrote:

there is no connection being initiated for port 10000 in log. the debug idea. was to stop other connections. but Ok. As for the link I sent, I was able to see the question of the rule. in this case I believe that you need an internal to internal rule.

But you didn't specify the port 10000 in your commands so I think the log is showing all connections regardless of port, right? 

Also I've got already an internal rule to reach internal3 (where the host with 192.168.1.12 IP resides) from internal1 (where I'm trying to reach it using the public IP instead the local one). In fact, as I've said ... when I use the local IP I'm able to reach it, but when I try to connect it using the public IP + port 10000 I cannot reach it. Which is strange, because internal1 has a policy to go outside and I can reach 192.168.1.12 machine from outside throught port 10000, so I don't understand anything.

[jorge_americo]

But you didn't specify the port 10000 in your commands so I think the log is showing all connections regardless of port, right? 

Also I've got already an internal rule to reach internal3 (where the host with 192.168.1.12 IP resides) from internal1 (where I'm trying to reach it using the public IP instead the local one). In fact, as I've said ... when I use the local IP I'm able to reach it, but when I try to connect it using the public IP + port 10000 I cannot reach it. Which is strange, because internal1 has a policy to go outside and I can reach 192.168.1.12 machine from outside throught port 10000, so I don't understand anything.

Yes Yes, I did not specify port 10000 because you do nat, so I wouldn't take everything. To make a more accurate test. can we use another port on this server? a port that does not have access to your network, just put only the port as a parameter in the diag. for example enabling a service on port XXX on your server and creating rules related to this port so that we can snifer and be cleaner. what do you think? it's viable ?

initially without nat