Client can ping, but can not curl (or browse)


#1

Hi, i’m newbie here…

i already install and configure Vyos on my network. it goes like this::

internet <-------> gateway <--------> vyos <---------> client
-----------------------------eth0---------eth0-eth1-----------eth0

gateway et0: x.x.x.x
vyos eth0: y.y.y.y (connect to internet)
vyos eth1: 192.168.5.20 (connect to intranet)
client eth0: 192.168.5.67

this is the config i made:
Capture1 Capture2 Capture3 Capture4 Capture5edit

i already set the ip, gateway, and name server on the client manually.

the output:

  1. from vyos, i can ping and curl any internet address, including the intranet client
  2. from client (192.168.5.67), i can ping to any internet address (ip and domain) including other client, but i can not curl (or browse) to the internet.

is there any config missing here? please help. thx…


#2

Hi!

The address in your nat source ... translation field, is that the same address thats configured on your ethernet interface? (its hard to tell because you’ve blanked out all octets of the address)

if thats the case you should use ... translation address masquerade instead to make it function properly.
The syntax you are using is men’t to be used when packets are routed into your device using other addresses than the interface-address.

also, on the incoming side(destination nat), you only need this part if you have services on your inside lan that you are going to expose to the internet. For normal outbound nat this is not needed. When you use the interface-address you don’t need to specify a destination address, but you will need to specify the ports that needs to be forwarded.

Also have a look at this documentation: https://wiki.vyos.net/wiki/NAT for examples


#3

yes, it is the same sir. i’m sorry for some reason i hide it.

i use 1-on-1 NAT based on vyos documentation below. and i use it because the client actually is a server.
Capture10

is it still ok to use masquerade when we want to expose a server?


#4

Hello, @facsi!
You don’t have the firewall rule to allow returning traffic from the internet to your intranet hosts. So requests from 192.168.5.67 are going to the Internet, but firewall blocks responses.


#5

Hi @zsdc, actually I already configure the firewall, take a look at firewall name ‘from-internet’. I believe the rule 1 is allowing http or https to go through client. And it implemented on eth0.

if the config is wrong, please let me know how it should be…


#6

Update:
I already change the config: nat source rule 1 translation to masquerade, but the problem persist.

additional info:

  1. the vyos & client is a VM inside VMWare.
  2. the vyos connected to vswitch0 that is connected to the internet, and vswitch1 that is connected to VMNetwork
  3. the client is connected to vswitch1.

I dont know if this additional info can help. But, thats it…
anyone?


#7

Hello, @facsi!
In your firewall first rule is:

  • if packet have protocol TCP
  • if destination in 192.168.5.67, 192.168.5.31
  • if destination port is 80, 443, 4443
  • then accept packet.
    And this rule is applied for incoming traffic on uplink interface.

So, for example, when 192.168.5.67 is trying to connect to any HTTPS server:

  • they sending request from one of high-numbered TCP ports, lets assume that this is 45000, to remote 443 port. This is allowed, because you do not configured filtration for outgoing traffic from intranet.
  • when remote host receive request, it sending answer by TCP from 443 port to 45000.
  • when this packet is received by your router, router use 1st firewall rule for checking. IP part of checking will be passed. But, because you allow only traffic to 80, 443, 4443 ports, and this answer have src 443 and dst 45000 ports, it will be blocked by firewall.

Your current ruleset is more looks like those, which can be used if you want to host websites on an address in “live” group.


#8

Wow thx @zsdc i forgot about those ephemeral port. That solve the problem!! :smiley:


closed #9

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.