This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Virtual-Cluster-IP cant be reached but should be

Hi,

today i wanted to modify our backup solution for our Postgres-Cluster (Hot-Standby-Master-Cluster) which uses a virtual ip that is managed by pacemaker and assigned to either of those two servers interfaces.

On the other side i have the firewall which allows connections to PG (tcp/5432) and this virtual ip but everytime i try to connect, the firewall drops the packages. when i change the virtual ip to the normal ip of the master it works.

Another point is, that the connections come from a site-2-site IPSec VPN from the Office but its allowed on all gateways and only the firewall directly before this virtual ip drops the connection but allows it when using the normal interface IP

Can someone help me find the issue here?
We are using the UTM 9.1


This thread was automatically locked due to age.
  • If the UTM is the firewall, please show us a representative drop line from the full Firewall log file (not the Live  Log).

    Cheers - Bob
  • Hi,

    sure. this one is such a line from the firewall log:
    11:30:34 Default DROP  TCP 10.0.60.5:35258 → 10.1.30.5:5432 [SYN] len=60 ttl=62 tos=0x00 srcmac=0:12:f2:9b:5d:0 dstmac=90:e2:ba:9:25:e8


    whereas the PF Rule is this:
    Backup Srv (10.1.60.5) -> Backup-Services (Srv-Group) -> 10.1.30.5 (Host)


    The Service Group includes services for PG 5432/tcp and some others, so it should work. Also when just adding the normal IP of the master server (10.1.30.11) the rules works, but not for this virtual ip (which you can only see on the master server with "ip addr show" but not if "ifconfig eth0"
  • Thanks, but that line is from the Live Log, and, alone among the Live Logs, the Firewall Live Log trades legibility for complete information.  Please post the corresponding line from the full Firewall log file.

    Also, is there a typo in your PF rule? Should that be 10.0.60.5?

    What happens if you do arping 10.1.30.5 from the command line?

    Cheers - Bob
  • Sorry,

    it should be the appropriate log line from the archived fw log file:
    2014:10:21-11:30:34 seth-1 ulogd[7508]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="lag1" outitf="lag0.30" srcmac="0:12:f2:9b:5d:0" dstmac="90:e2:ba:9:25:e8" srcip="10.0.60.5" dstip="10.1.30.5" proto="6" length="60" tos="0x00" prec="0x00" ttl="62" srcport="35258" dstport="5432" tcpflags="SYN" 


    And yeah, sure it IS 10.0.60.5 (was a typo from me)
  • "60002" => drop out of the FORWARD chain

    Are you sure that your Host definition for 10.1.30.5 doesn't violate #3 in Rulz?

    Cheers - Bob
    PS arping 10.1.30.5
  • No it does not violate rule 3 (see attached picture).

    The output of arping is this:
    arping 10.1.30.5
    ARPING 10.1.30.5 from 198.19.250.1 eth0
    ^CSent 10 probes (10 broadcast(s))
    Received 0 response(s)


    Don't know why there is "from 198...."
  • If 10.1.30.5 is connected to eth2, try:

    arping -I eth2 10.1.30.5


    Cheers - Bob
  • Hi,

    ive tried arping from all avail. ifaces (eth0-6 and lag0/1) but none of them worked. no arp response [:(]
  • Which interface is connected to the PGSQL cluster, and what Address is on the interface?  What Broadcast address is associated to 10.1.30.5 on the PGSQL device?

    Cheers - Bob
  • Hi,

    sorry for the delay. the PG Cluster is connected on LAG0 (eth0 and eth1) in the VLAN 30 (Database-VLAN).
    An "ip addr show" on the actual Cluster Master server shows:
    inet 10.1.30.5/24 brd 10.1.30.255 scope global secondary bond0