Hot!Acessing to Virtual IP from the inside

Author
jfernandz
Bronze Member
  • Total Posts : 25
  • Scores: 0
  • Reward points: 0
  • Joined: 2021/04/22 09:02:58
  • Status: offline
2021/05/25 07:14:53 (permalink)
0

Acessing to Virtual IP from the inside

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.
 
 
 
 
post edited by jfernandz - 2021/05/25 07:26:58
#1

13 Replies Related Threads

    jorge.americo
    Bronze Member
    • Total Posts : 40
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/06/12 06:49:38
    • Location: Bahia/Brasil
    • Status: offline
    Re: Acessing to Virtual IP from the inside 2021/05/25 08:06:40 (permalink)
    0
    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.
    #2
    jfernandz
    Bronze Member
    • Total Posts : 25
    • Scores: 0
    • Reward points: 0
    • Joined: 2021/04/22 09:02:58
    • Status: offline
    Re: Acessing to Virtual IP from the inside 2021/05/25 14:01:42 (permalink)
    0
    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.




    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.
    post edited by jfernandz - 2021/05/25 23:56:12
    #3
    jorge.americo
    Bronze Member
    • Total Posts : 40
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/06/12 06:49:38
    • Location: Bahia/Brasil
    • Status: offline
    Re: Acessing to Virtual IP from the inside 2021/05/25 16:19:46 (permalink)
    0
    # diag debug enable
    diagnose debug flow filter saddr x.y.w.z
    # 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.
     
    [font="verdana; font-size: 14px"]see this .
    [font="verdana; font-size: 14px"] https://kb.fortinet.com/k....do?externalID=FD36202
    #4
    jfernandz
    Bronze Member
    • Total Posts : 25
    • Scores: 0
    • Reward points: 0
    • Joined: 2021/04/22 09:02:58
    • Status: offline
    Re: Acessing to Virtual IP from the inside 2021/05/26 00:06:30 (permalink)
    0
    jorge.americo
    # diag debug enable
    diagnose debug flow filter saddr x.y.w.z
    # 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.
     
    [font="verdana; font-size: 14px"]see this .
    [font="verdana; font-size: 14px"] 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)
    #5
    jorge.americo
    Bronze Member
    • Total Posts : 40
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/06/12 06:49:38
    • Location: Bahia/Brasil
    • Status: offline
    Re: Acessing to Virtual IP from the inside 2021/05/26 06:27:58 (permalink)
    0
    jfernandz
    jorge.americo
    # diag debug enable
    diagnose debug flow filter saddr x.y.w.z
    # 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.
     
    [font="verdana; font-size: 14px"]see this .
    [font="verdana; font-size: 14px"] 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?
    #6
    jfernandz
    Bronze Member
    • Total Posts : 25
    • Scores: 0
    • Reward points: 0
    • Joined: 2021/04/22 09:02:58
    • Status: offline
    Re: Acessing to Virtual IP from the inside 2021/05/26 07:21:17 (permalink)
    0
    jorge.americo
     
    [...]
    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
    #7
    jorge.americo
    Bronze Member
    • Total Posts : 40
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/06/12 06:49:38
    • Location: Bahia/Brasil
    • Status: offline
    Re: Acessing to Virtual IP from the inside 2021/05/26 11:17:09 (permalink)
    0
    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.
    #8
    jfernandz
    Bronze Member
    • Total Posts : 25
    • Scores: 0
    • Reward points: 0
    • Joined: 2021/04/22 09:02:58
    • Status: offline
    Re: Acessing to Virtual IP from the inside 2021/05/26 14:21:08 (permalink)
    0
    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.




    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.
    #9
    jorge.americo
    Bronze Member
    • Total Posts : 40
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/06/12 06:49:38
    • Location: Bahia/Brasil
    • Status: offline
    Re: Acessing to Virtual IP from the inside 2021/05/27 06:20:12 (permalink)
    0
     
    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
    #10
    jfernandz
    Bronze Member
    • Total Posts : 25
    • Scores: 0
    • Reward points: 0
    • Joined: 2021/04/22 09:02:58
    • Status: offline
    Re: Acessing to Virtual IP from the inside 2021/05/27 06:40:04 (permalink)
    0
    Well, I've been checking the logs and I think this is because of my ISP.
     

     
    As you can see, despite I'm always (in both cases) doing the request to the office public IP (83.x.y.143)
    • When I open the connection from outside (source=176.83.47.77), FortiGate actually uses 217.124.116.61 as destination IP (the ISP gave me this IP to set the WAN1 IP/Netmask, which is actually connected to the ISP router)
    • When I open the connection from inside (source=172.20.1.16), FortiGate uses the actual public IP (83.x.y.143), but it's not forwarding/natting properly the connection to the right local IP (192.168.1.12) and port (80). If I do the request to 217.124.116.61:10000 from inside it works as expected, but 217.124.116.61 is not available from outside ... 
    So maybe this is because the network architecture of my ISP, what do you think?
    post edited by jfernandz - 2021/05/27 08:09:41
    #11
    jorge.americo
    Bronze Member
    • Total Posts : 40
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/06/12 06:49:38
    • Location: Bahia/Brasil
    • Status: offline
    Re: Acessing to Virtual IP from the inside 2021/05/27 12:04:07 (permalink)
    0
    Perfect. then we have to see something on that WAN.
    how is it configured?
    where does ip 83 come from? is a valid ip routed by your operator to you? the IP 217.124.116.61 is configured on your WAN, correct?
    the request has been made by IP or DNS?
    One more question, you informed:
    If I do the request to 217.124.116.61:10000 from inside it works as expected, but 217.124.116.61 is not available from outside ...
    Do you have a macro drawing of your topology? to try to understand better
    #12
    jfernandz
    Bronze Member
    • Total Posts : 25
    • Scores: 0
    • Reward points: 0
    • Joined: 2021/04/22 09:02:58
    • Status: offline
    Re: Acessing to Virtual IP from the inside 2021/05/28 00:17:04 (permalink)
    0
    jorge.americo
    Perfect. then we have to see something on that WAN.
    how is it configured?
    where does ip 83 come from? is a valid ip routed by your operator to you? the IP 217.124.116.61 is configured on your WAN, correct?
    the request has been made by IP or DNS?
    One more question, you informed:
    If I do the request to 217.124.116.61:10000 from inside it works as expected, but 217.124.116.61 is not available from outside ...
    Do you have a macro drawing of your topology? to try to understand better




    • As I've said, WAN1 has as IP/Netmask just that value (217.124.116.61)
    • The IP 83 is the IP that services for knowing your public IP report to me, for example this one
    • I'm always doing the request by IP, of course.
     
    I'm not sure if this will help, but this is a little schema representing what I have.
     

     
    217.124.116.x IPs were given to me by the ISP in order to set the these two things (WAN1 interface IP/Netmask and the shown static route), but actually the 83.x.y.143 IP is the IP that public services for knowing your public IP report to me.
     
    Again, as I've said ... 217.124.116.x IPs are not accessible from outside, I guess those IPs have something to do with the configured DMZ by the ISP, I can ping them just when I'm at the office.
     
     
     
     
    post edited by jfernandz - 2021/05/30 23:45:23
    #13
    jorge.americo
    Bronze Member
    • Total Posts : 40
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/06/12 06:49:38
    • Location: Bahia/Brasil
    • Status: offline
    Re: Acessing to Virtual IP from the inside 2021/05/28 07:39:00 (permalink)
    0
    As I understand it, your provider grants you a valid IP but still does a NAT for the internet. In this case, you have to ask them to do 83. routing for your equipment and change your VIP from "0.0.0.0 -> 192.168.1.12 (TCP: 10000 -> 80)" to "83.xyz -> 192.168. 1.12 (TCP: 10000 -> 80) "
    Obs. Put the wan interface in the VIP so that there is the gratuitous arp and your equipment is presented to the provider as 83.
    #14
    Jump to:
    © 2021 APG vNext Commercial Version 5.5